Support 1920 kHz sample rate
troosh opened this issue · 3 comments
Please support 1920 kHz sampling rate.
It was required to work with raw data collected on a cell phone in the Android application RF Analyzer. There is little traffic in my area, so I used this method elsewhere by the river to get the sample files. Unfortunately RF Analyzer application supports other multiples of the 96 kHz sampling rates: 1920 kHz and 2400 kHz. To support them, a 5 times decimation filter is required.
In addition, a better signal-to-noise ratio can be obtained by using a higher sampling rate.
I tried to do it myself, but my modifications are no longer relevant:
7336fa7 fb9b6bb
Test files can be taken here.
Hi, many thanks for your feedback. I have looked at your suggestions and I think that will work.
Apologies for breaking the changes; I had rewritten the downsample function to make it more general and flexible so to fix the USB transfer buffer at a multiple of 16KB. The new code however also made it easy to accommodate for a few more sample rate choices which I coincidentally put in over the weekend (1920K and 2304K). Will commit later today.
I tried to run AIS-catcher on your files and I found 186 and 77 messages (vs 192 and 76). However, there is some room for further tuning of the filter. Another interesting observation is that the difference between the different decoding models is quite small for your files. I will add them to the test set to see if we can squeeze out a bit more.
Hope that works for you. Thanks.
I am grateful to you for this project, thanks!. I plan to use it in my station instead of AiSDeco2 on raspberrypi 2.
The Challenger model at version 0.12 is tolerant of no ppm correction. My blue dong requires 38 ppm, but if this is not done, 45% of the packets will still be recognized (other models do not recognize anything). I added new files to my samples folder.
Correction of 38 ppm compensates for a frequency shift of 6 kHz, the same shift is obtained due to the Doppler effect when the receiver moves with speed of ~11 km/s (second cosmic speed!). ;) Is it necessary to have such a margin of tolerance? Perhaps this is useful for those who have a very bad generator in dongle, but it requires more processor performance. But this was fixed at version 0.15.
You are right. In later updates I have restricted the range for the frequency correction. Main driver was that the detection rate improved and not so much from an efficiency perspective. Although this helped as well.
Thank for sharing your files. I add them to a signal database that I use to test a new decoding model I am building and smaller updates. The more samples I have from various environments the better.
Let me know how it goes with getting it to run on the RPI2. I will close this issue now.
Thank you.