Hello, and I wrote OOKwiz

Moderators: rtenklooster, Voyager, BertB, Stuntteam

Post Reply
Message
Author
rop
New user
Posts: 4
Joined: 14 Feb 2024, 12:43

Hello, and I wrote OOKwiz

#1 Post by rop » 14 Feb 2024, 13:13

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
Attachments
OOKwiz.png
OOKwiz.png (509.01 KiB) Viewed 295 times

TD-er
Core team member
Posts: 8739
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Hello, and I wrote OOKwiz

#2 Post by TD-er » 14 Feb 2024, 14:44

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
New user
Posts: 4
Joined: 14 Feb 2024, 12:43

Re: Hello, and I wrote OOKwiz

#3 Post by rop » 14 Feb 2024, 15:50

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
Core team member
Posts: 8739
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Hello, and I wrote OOKwiz

#4 Post by TD-er » 14 Feb 2024, 16:16

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
New user
Posts: 4
Joined: 14 Feb 2024, 12:43

Re: Hello, and I wrote OOKwiz

#5 Post by rop » 14 Feb 2024, 16:27

TD-er wrote: 14 Feb 2024, 16:16 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
New user
Posts: 4
Joined: 14 Feb 2024, 12:43

Re: Hello, and I wrote OOKwiz

#6 Post by rop » 19 Feb 2024, 13:16

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest