Hello, and I wrote OOKwiz

[rop]

Hi there,

I think I wrote something that might interest the rest of the community here. It's called OOKwiz, it deals with on/off keyed radio signals, it's open source (LGPL3) and I think it can serve as a solid and time-saving foundation for some of the things people are building here.

Please check it out: https://github.com/ropg/OOKwiz

[TD-er]

Welcome Rop
I've been a long time fan of your projects. (e.g. playing chess on voting machines was hilarious and also clearly making your point)

I took a very brief look at the code and I was wondering why you only describe calling a loop() function and not schedule a RTOS task on a core and set a RTOS timer to call this task?

Any idea how blocking the calls are to act on interrupts when receiving data?
Perhaps we can make a plugin (or 2) for this, similar to the IR plugins.

[rop]

I've given thought to making what is now loop() its own task but decided against it because I figured this way gives the user more control over when to run other things. Also it's not critical as loop() doesn't need to run often, only often enough to pick up every unique packet. And things get hairy quickly when there's serial output from multiple tasks. Not sure what you mean with your question on blocking calls: there's only two ISRs. The inner workings are described here: https://github.com/ropg/OOKwiz?tab=read ... r-workings

The device plugin mechanism makes turning this into something like RFlink super easy because most plugins will not need to do any decoding of the actual intervals. There's even an RFLINK serial output macro that prepends the "20;<seq>;" and works like printf otherwise.

I think the ideal device plugin should do both RFLINK-format input/output (which the user should then be able to enable/disable globally) and offer all the properties of a device via MQTT.

[TD-er]

What I meant is that some of the supported radio modules hardly do anything themselves other than just outputting "pulses" after mixing down from the tuned frequency.
So if it is only registering the time since last pulse and recording it to a pre-allocated array of memory, then it isn't blocking.
But if you need to "wait" to filter out some noise or actively request a value, then it is blocking. (especially when on a shared bus like with SPI)

N.B. if you're looking for boards with the SX1276, you may want to check out LilyGo T-beam boards.
Especially the older ones have those "SX127x" chips. The newer ones (also quite a bit more expensive) have the SX126x chips.
Lilygo has made quite a lot LoRa boards in the past, some smaller with their own display.

If you go for the T-beam and want to add one of those SSD1306 OLED displays, double check the order of the I2C pins as they used the rarest pin order in existence for those displays. They do sell those displays too as it might be hard to find them elsewhere and you may end up with adding some bad looking wiring mess... (ask me how I know )

[rop]

What I meant is that some of the supported radio modules hardly do anything themselves other than just outputting "pulses" after mixing down from the tuned frequency.
So if it is only registering the time since last pulse and recording it to a pre-allocated array of memory, then it isn't blocking.
But if you need to "wait" to filter out some noise or actively request a value, then it is blocking. (especially when on a shared bus like with SPI)

Normally these ISRs are done almost instantly. Only at the end of a packet (as determined by pulse_gap_len_new_packet period of either tranmission or silence, or the exceeding of noise_threshold, the ISR-handling takes a tiny bit longer for noise fixing, normalization and comparison with previous packet (if repeat_timeout not exceeded). But even that finishes in microseconds, not milliseconds.

N.B. if you're looking for boards with the SX1276, you may want to check out LilyGo T-beam boards.
Especially the older ones have those "SX127x" chips. The newer ones (also quite a bit more expensive) have the SX126x chips.
Lilygo has made quite a lot LoRa boards in the past, some smaller with their own display.

If you go for the T-beam and want to add one of those SSD1306 OLED displays, double check the order of the I2C pins as they used the rarest pin order in existence for those displays. They do sell those displays too as it might be hard to find them elsewhere and you may end up with adding some bad looking wiring mess... (ask me how I know )

I guess for now I'm holding out for someone that has one of these boards to verify that the plugin works.

[rop]

I just released v0.2.0 that fixes a bug that caused the previous two versions not to work if there were no prior settings in SPIFFS. Also moved the normalization and deduplication to the OOKwiz::loop() task, so the ISRs are now truly skinny.

[TD-er]

Maybe also nice to look at this video: https://www.youtube.com/watch?v=eIdHBDSQHyw

It does create LoRa packets using 'bitbanging' of PLL registers to generate chirps at 900 MHz on a GPIO.
This is on an ESP8266/ESP32-S2 and CH32V203.

This is absolutely not nice to the Ether as it will be putting quite a lot of noise in all harmonics frequencies.
But it is nice to see what is possible using really low-level tinkering.