On Sun, Aug 5, 2012 at 10:14 AM, Christian Gagneraud <[email protected]>wrote:
> On 18/07/12 18:21, Nick Foster wrote: > >> Take a look at gr-air-modes for details on how I did it there. >> gr-osmosdr follows the UHD API for the most part, so a lot of it drops >> in pretty easily. I'm not going to pull in a patch which makes the >> receiver depend on gr-osmosdr, but I'm happy to have a command-line >> option (or even autodetect) for gr-osmosdr support for FCD and RTL. >> > > Hi Nick, > > I managed to get gr-ais working both with FCD and RTL using gr-osmosdr. > The changes to gr-ais are really straight forward. > Can you tell me why you don't want dependency on gr-osmosdr? As you said, > this driver follows the UHD API, so it is very easy to use it in place of > the UHD one, with the added advantage of supporting other hardware. > So using osmosdr would make the code cleaner and allow support for other > hardware, but adding an option/autodetection will just add useless > boilerplate. > It effectively adds an unnecessarily dependency on gr-osmosdr for UHD users. The required boilerplate is pretty minimal; since the interfaces are essentially identical, you can just wrap the import in a try/except and use gr-osmosdr if available, gr-uhd otherwise. You need the rest of the boilerplate anyway to handle the different sample rate requirements of the different dongles. > > Anyway, I just found that Antoine Sirinelli already added basic support > for rtl-sdr, although not tested: > https://github.com/asirinelli/**gr-ais<https://github.com/asirinelli/gr-ais> > I'm gonna test it, but he's at least missing the decimation filter change > (RTL can't sample at 256KHz, so I used 1.024MHz with a decimation filter > factor of 16) > > > >> I haven't tried AIS on RTL at all, and I expect there to be some >> filtering/LO offset tuning required to achieve decent results on it. >> > > I don't know how decent are my results with RTL (at least as good as with > FCD, but definitely not as good as a real AIS receiver), but the only > "tunning" I did was to use the right sampling rate (wrong sampling rate > gives you a frequency shift) and of course the the frequency correction > (107 ppm in my case). > Recent versions of gr-ais incorporate a reasonably robust frequency estimator based on the square-and-FFT method. It works "okay" for GMSK modulations, especially for strong signals. There are smarter things you can do that someday I hope to have the time to implement. =) At any rate, it should have a reasonably large capture bandwidth. 17kHz (107ppm at 162MHz) might be stretching those limits, though. That's pretty bad. You sure they're not using, like, a clarinet reed as a frequency reference? --n > > Chris > > >> --n >> >> On Wed, Jul 18, 2012 at 2:49 AM, Christian Gagneraud <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 18/07/12 09:13, Darren Long wrote: >> >> Hi Chris, >> >> Might I be so bold to suggest that in your efforts, you consider >> using >> the gr-osmosdr abstraction >> >> (http://sdr.osmocom.org/trac/_**_wiki/GrOsmoSDR<http://sdr.osmocom.org/trac/__wiki/GrOsmoSDR> >> >> <http://sdr.osmocom.org/trac/**wiki/GrOsmoSDR<http://sdr.osmocom.org/trac/wiki/GrOsmoSDR> >> >) >> >> so that the RTL-SDR could be used too. In fact it supports UHD, >> FCD and >> RTL-SDR, and works well in gqrx for example. >> >> >> Hi, >> >> That sounds interesting, actually, that was on my plan to try the >> RTL hardware once I'm happy enough. If i'm not wrong this RTL is the >> related to the chip found on some cheap DVB receiver, isn't it? >> >> AFAIU, the ais_rx.py script is half about setting up UHD, and half >> about the decoding itself. >> I just had a look at gr-osmosdr, and it seems so far quite straight >> forward to use. >> >> Nick has just updated his git repo with the cmake branch. I'll give >> it a try tonight. >> >> Nick, do you have any thought on this? It would be really nice to >> get ais_rx.py be usable with different hardware. >> >> Chris >> >> >> >> Sorry for being cheeky :P >> >> >> You wasn't, it sounds like a good idea indeed! >> >> Chris >> >> >> >> Darren >> >> On 17/07/12 22:43, Christian Gagneraud wrote: >> >> On 17/07/12 22:24, Nick Foster wrote: >> >> Christian, >> >> Are you using the version found here? >> >> >> https://github.com/bistromath/**__gr-ais<https://github.com/bistromath/__gr-ais> >> >> >> <https://github.com/**bistromath/gr-ais<https://github.com/bistromath/gr-ais> >> > >> >> If not, please use this version, as it is significantly >> more up-to-date >> than the one on CGRAN. I'm going to change the CGRAN >> page to point to >> the Github repository. >> >> >> Interesting. >> >> Would you be interested in getting it ported to the new >> build system? >> If so, I'll redo the work on your tree. >> As well, I realised that ais_received.py is tailored for the >> USRP. >> I'm currently using a funcube dongle, so I might as well >> contribute >> with a dedicated script, once i start to get things working. >> >> Chris >> >> >> >> --n >> >> On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> >> wrote: >> >> On 17/07/12 21:31, Josh Blum wrote: >> >> >> >> On 07/17/2012 01:27 PM, Christian Gagneraud >> wrote: >> >> Hi, >> >> I tried to build >> https://cgran.org/wiki/AIS against >> gnuradio-3.6, and i >> fails. >> As 3.6 brings in a new build system, I >> decided to give it a >> go on the >> AIS module. I based everything on >> gr-howto-write-a-block >> >> [...] >> >> ImportError: >> >> /usr/local/lib/python2.7/site-** >> ____packages/ais/_ais_swig.so: >> >> undefined symbol: _Z14ais_make_shiftv >> >> >> Just a guess, but >> >> In gnuradio we explicitly export the library >> symbols. If you >> arent doing >> that for libgnuradioais, make sure that the >> visibility flag is >> being set >> to default. You can read more here: >> >> http://gcc.gnu.org/wiki/____**Visibility<http://gcc.gnu.org/wiki/____Visibility> >> >> <http://gcc.gnu.org/wiki/__**Visibility<http://gcc.gnu.org/wiki/__Visibility> >> > >> >> >> <http://gcc.gnu.org/wiki/__**Visibility<http://gcc.gnu.org/wiki/__Visibility> >> >> <http://gcc.gnu.org/wiki/**Visibility<http://gcc.gnu.org/wiki/Visibility> >> >> >> >> >> Hi Josh, >> >> Actually, I've just discovered this was needed! >> So, yes that was it. >> No it's complaining about usrp stuff, but it's >> another story. I >> don't have a USRP, I'm using a FUNcube dongle. >> >> BTW, should I make this package install in >> lib/python2.7/site-packages/__**__gnuradio/ais >> instead of >> lib/python2.7/site-packages/__**__ais >> >> Same with the include dir: include/gnuradio/ais >> instead of >> include/ais? >> >> I would like to be able to use gnuradio-companion, >> and pick up the >> AIS block from the selection list, but it's not >> there. This might be >> due to the current install dir. Any comment? >> >> Chris >> >> >> >> >> >> -josh >> >> >> ______________________________**_____________________ >> >> Discuss-gnuradio mailing list >> [email protected] >> <mailto:Discuss-gnuradio@gnu.**org<[email protected]> >> > >> <mailto:Discuss-gnuradio@gnu._**_org >> <mailto:Discuss-gnuradio@gnu.**org<[email protected]> >> >> >> https://lists.gnu.org/mailman/** >> ____listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/____listinfo/discuss-gnuradio> >> <https://lists.gnu.org/**mailman/__listinfo/discuss-** >> gnuradio <https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>> >> >> <https://lists.gnu.org/__**mailman/listinfo/discuss-__* >> *gnuradio <https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio> < >> https://lists.gnu.org/**mailman/listinfo/discuss-**gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> >> >> >> >> >> -- >> Christian Gagneraud, >> Embedded systems engineer. >> Techworks Marine >> 1 Harbour road >> Dun Laoghaire >> Co. Dublin >> Ireland >> Tel: + 353 (0) 1 236 5990 >> <tel:%2B%20353%20%280%29%201%**20236%205990> >> <tel:%2B%20353%20%280%29%201%_**_20236%205990> >> Web: http://www.techworks.ie/ >> >> >> >> ______________________________** >> _____________________ >> >> Discuss-gnuradio mailing list >> [email protected] >> <mailto:Discuss-gnuradio@gnu.**org<[email protected]> >> > >> <mailto:Discuss-gnuradio@gnu._**_org >> <mailto:Discuss-gnuradio@gnu.**org<[email protected]> >> >> >> https://lists.gnu.org/mailman/** >> ____listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/____listinfo/discuss-gnuradio> >> <https://lists.gnu.org/**mailman/__listinfo/discuss-** >> gnuradio <https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>> >> >> <https://lists.gnu.org/__**mailman/listinfo/discuss-__* >> *gnuradio <https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio> < >> https://lists.gnu.org/**mailman/listinfo/discuss-**gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> Discuss-gnuradio mailing list >> [email protected] >> <mailto:Discuss-gnuradio@gnu.**org<[email protected]> >> > >> >> https://lists.gnu.org/mailman/**__listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio> >> >> <https://lists.gnu.org/**mailman/listinfo/discuss-**gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> > >> >> >> >> -- >> Christian Gagneraud, >> Embedded systems engineer. >> Techworks Marine >> 1 Harbour road >> Dun Laoghaire >> Co. Dublin >> Ireland >> Tel: + 353 (0) 1 236 5990 <tel:%2B%20353%20%280%29%201%** >> 20236%205990> >> Web: http://www.techworks.ie/ >> >> >> >> > > -- > Christian Gagneraud, > Embedded systems engineer. > Techworks Marine > 1 Harbour road > Dun Laoghaire > Co. Dublin > Ireland > Tel: + 353 (0) 1 236 5990 > Web: http://www.techworks.ie/ >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
