Update pocsag decoder #426
Conversation
This is the POCSAG code before reformat to put smooth and extract packets in the correct place
Removed unused items from the UI
Left in the message for the moment, because there are likely to be parameters needed at some point.
|
Hey! thanks for the improved version 👍 it needs to get exposed it in our discord's testdrive channel |
Hi Eried, I'm sorry I am not familiar with the "testdrive channel". Is this something that I do, or something that gets handled by the pull request review process (or something else)? |
|
Looks like something was wrong with the antenna I was using. |
Hi! not much, in the main readme there is a link for our discord, and inside there is a channel where you can ask users to test stuff 💯 |
|
Testing this now and I'm loving it. If I had 2 hackrf I could send pocsag messages to ensure they're all getting through but I'm happy it's pulling in more messages than it was before. Thanks for your efforts it's a yes from me! |
|
Great work, thank you! |
|
Great work updated and can confirm the POCSAG decoder does not freeze anymore |
|
@heurist1 are you still around ? |
Hi The POCSAG decoder was not very sensitive. It was also limited because it required the user to know the baud rate and inversion of the signal. Example data that I can get hold of has multiple baud rates on a single RF channel.
Around 20 years ago I wrote a decoder that worked from the discriminator output of a scanner, fed into the soundcard of a PC. I have ported the decoding section of this, and made it work with the POCSAG GUI aspect of the Portapac. As there is no need to set a baud rate or inversion, I have removed those elements from the GUI.
I noted that between me starting this work and now a new baud rate had been added, so I have set the smoothing so that it should still work well at this rate, but I only have access to signals at 512 1200 and 2400 for testing.
I kept the frame extractor in a separate class during development, so that it could be run in both Portapac and my old software, as that made development and debugging easier, but I have merged it back now. I spent quite a while converting it to use scaled integers rather than floats. I scaled all values by 1024, but actually I’m not convinced that it works that much faster, I’m also not sure how to know exactly how much CPU it is using.
There is a small helper class to smooth the signal which may be more correctly part of “dsp” but I’m not sure what the project policy is on this.
Maybe there is a standard test that you run against the code before a release, but I hadn’t spotted that in the repository. If there is a test, please could someone send a link to it so I could run my code against it. I could even expand the test to include multiple rates and inversion in a single file.
If you observe any issues with the code and would like them fixing before accepting the pull request, please let me know, and within reason, I’m sure I can find time to work on them.
Cheers
Simon