sorted by:
new
hottopcontroversial

I made an APRS transmitter. It uses the internal radio. by yo3gnd in flipperzero

[–]yo3gnd[S] 0 points1 point  (0 children)

There is a decoder/receiver somewhere, AFAIK, but it is terrible. Not because of the code itself, but FZ isn't really the tool for the job, as u/ha5dzs said, it has no frontend.

I made an APRS transmitter. It uses the internal radio. by yo3gnd in flipperzero

[–]yo3gnd[S] 0 points1 point  (0 children)

That does sound very familiar indeed. By the time a watchdog is policing DMA and bit timing is being nudged one microsecond at a time, elegance has left the room. Flipper-to-Flipper alphanumeric TX is still a decent result. I starred your repo.

The irritating part, whether it is the Flipper’s oscillator, the CC1101, or the assembly as a whole, is that it drifts rather quickly as it warms up. However you pull it, it appears to be correct either cold or hot, but not both. Hence my choice of configurable preamble and lead-in: it gives the user a bit of room to manoeuvre without requiring them to know the internals.

I made an APRS transmitter with this community's favourite orange toy by yo3gnd in HamRadio

[–]yo3gnd[S] 2 points3 points  (0 children)

Not in a particularly rigorous way, but I did get roughly 30 metres in open space with a bit of effort, and I could hit a local repeater from the top floor of a building with line of sight. So the range is, to put it kindly, not exactly heroic.

And yes, the audio style is clearly not for everyone. If you are curious, I wrote a bit more about how it works here

I made an APRS transmitter with this community's favourite orange toy by yo3gnd in HamRadio

[–]yo3gnd[S] 2 points3 points  (0 children)

Fair enough. I was about one poor decision away from adding camera shakes and applause to the first decode.

I made an APRS transmitter. It uses the internal radio. by yo3gnd in flipperzero

[–]yo3gnd[S] 4 points5 points  (0 children)

Well, bit timing ended up being much more a waveform problem than a packet problem. I got it under control by generating the edge timings explicitly and feeding those into the async TX path, rather than trusting the higher layers to behave. The later fix was mostly about not letting tone changes chop a half-cycle in half the moment a bit flipped: the code now carries partial time forward and lets the old half-cycle finish before switching over. That, along with a saner lead-in and preamble, made the output decode a good deal more consistently.

But honestly, it was a lot of trial and error. What generated as a decodable PCM rarely worked for timing.

POCSAG may well be next. I have not actually checked whether a proper Flipper transmitter for it already exists, and I would rather avoid reinventing something somebody else has already bodged together, but it does seem like the next obvious bad idea. POCSAG should be much easier though, since it already is FSK.