Output dmesg over radio
ea opened this issue · comments
It would be nice to be able to dump the debug messages over radio, in case something weird happens.
I've started work on this and have an app that does TX-ing. It will likely need more testing and tweaking of packet sizes , and a proper RX side (rtlsdr script even?). Will be on my branch until ready.
Comments?
This would be handy!
Best bet is probably to have the host computer listening at all times, with the device radio dumping dmesg every hour when configured to do so, and also once at startup of the prior boot's dmesg.
I've been playing around with this and it appears that if the battery is anything less than completely new , and dmesg buffer is a bit long, sending packets very quickly one after another causes a reboot itself. The artificial delay in the transmit loop seems to alleviate this a bit and also helps the receiver keep up.
Currently there are two ways to receive the dmesg log. One, through goodwatch.py and option -B , which might require a bit of timing, but seems to work fairly well for me (it also requires two watches). And two, through supplied rtlsdr GnuRadio script, which is seems much cleaner, if one has an rtlsdr lying around.
To go with gnuradio route, one first runs goodwatch_sniff.py script which will dump bits into test.bin. One might need to fiddle with PPM correction and frequency settings in the goodwatch_sniff.grc if it doesn't work out of the box (my rtlsdr has a particularly high PPM correction requirement). Then, after the packets are transmitted, running decode_goodwatch.py should spit out the dmesg log.
Anybody willing to test this? To make sure it doesn't suffer from the old "works on my machine only" illness...
It would indeed be cool to have it chirp out only new messages every hour, if in "debug" mode of some sort, but I need to figure out how to schedule it first and how to do a tx callback from outside an app :).
I should have time to try it out this week.
@ea You might try updating your fork to master, then transmitting packets of just the battery voltage, to see where it fails.
@ea I merged the beginnings of a dmesg application. For now, it just scrolls the buffer on the screen, but we can merge radio code into it soon.
Ah, i see where you are going with this. Neat. I was just playing with the gnuradio receiver the other day and made it easier to use. The trouble was in figuring out the exact frequency due to drift in different SDRs. I'll update my fork and add some code that might be useful.
We also have a bit of our own drift. Perhaps we can calibrate for it, the same way we do the RTC correction?
I have seen pretty large drifts between 3-4 devices i have, but i suspect one to be an outlier due to poor soldering on my side. I don't have a gw30 built yet so i'd stay out of that.
I added a simple gnuradio rtlsdr script that can receive messages as sent by beacon app (and my prototype dmesg sending app) here https://github.com/ea/goodwatch/tree/sdr_testing/bin/sdr
I didn't make a pull request as i'm unsure if you want to taint your repo with sdr stuff, but thought i'd point it out in case somebody ends up needing it.