Support user supplied protocol timings from host for receive decoding

[otsoni]

Nexa devices are using 64-bit codes, but uart TX buffer is too small (48 at the moment) for sending those. Would it be too bad to handle the uart TX in a blocking way? I can make a pull request for that if needed.

[mightymos]

Hi @otsoni , original portisch used just TX = 32 bytes, but as you say for sniffing long codes that can be too little. However, I now block for sending in uart_put_RF_buckets() as portisch also did. I just need to produce a new release very soon with these fixes.

[mightymos]

Nexa devices are using 64-bit codes, but uart TX buffer is too small (48 at the moment) for sending those. Would it be too bad to handle the uart TX in a blocking way? I can make a pull request for that if needed.

If you're willing to test the latest release with your devices and let me know how it goes, that would be very helpful:
https://github.com/mightymos/RF-Bridge-OB38S003/releases/tag/v0.4.4

Another user has had some good success recently:
#11

[otsoni]

I realized after I had send my first message that you already had been working on with something, but I hadn't pulled the code for some time. It seems to be working now and thank you very much, I really appreciate your work with this.

I tried myself different approach to blocking uart and you can check it from my fork (https://github.com/otsoni/RF-Bridge-OB38S003/tree/blocking-uart) if you want. It would save a ton of RAM and also some Flash memory, but it is not fully tested. I think that the sending works ok, but not sure if that kind of system can miss some receiving data if there is somehing taking too long on main while loop.

[mightymos]

I realized after I had send my first message that you already had been working on with something, but I hadn't pulled the code for some time. It seems to be working now and thank you very much, I really appreciate your work with this.

I tried myself different approach to blocking uart and you can check it from my fork (https://github.com/otsoni/RF-Bridge-OB38S003/tree/blocking-uart) if you want. It would save a ton of RAM and also some Flash memory, but it is not fully tested. I think that the sending works ok, but not sure if that kind of system can miss some receiving data if there is somehing taking too long on main while loop.

Ah okay, sure I'll take a look. Might be possible to test a version like that and see how well it performs with real devices.

I noticed you did some makefile edits as well.
Do you happen to know if it's possible to pass in a symbol from a makefile into a source file based on the compilation target?
The idea would be to perform some conditional compilation in a source file based on if the target was rcswitch versus portisch.

[otsoni]

I didn't chage souces of other targets so they didn't compile and I just needed a way to build only the portisch version. I don't have deep understanding of makefiles, but I can try to find some solution.

[otsoni]

I checked and you can define preprocessor macro with command line option -D for sdcc (other compilers too). All releases should then have their own versions compiled of that file. I am on my phone, but can check it later when I'm back on my computer

[mightymos]

I checked and you can define preprocessor macro with command line option -D for sdcc (other compilers too). All releases should then have their own versions compiled of that file. I am on my phone, but can check it later when I'm back on my computer

Got it, no problem, I'll look into it as well.

[otsoni]

I was thinking if it would be possible to extend the Portisch commands? As there is limited amount of RAM, it is not possible to have all the protocols defined in the firmware. I was thinking if there could be new command for "teaching" protocols for the OB38S003.

So that there is no protocols at all (or just really basic one for backwards compatibility) defined and then esphome or tasmota would call the new command for the protocols that are wanted to use. Then there could be a lot of protocols defined in esphome or tasmota and it teaches the necessary protocols for the OB38S003.

Does this sound like somthing doable?

[mightymos]

I was thinking if it would be possible to extend the Portisch commands? As there is limited amount of RAM, it is not possible to have all the protocols defined in the firmware. I was thinking if there could be new command for "teaching" protocols for the OB38S003.

So that there is no protocols at all (or just really basic one for backwards compatibility) defined and then esphome or tasmota would call the new command for the protocols that are wanted to use. Then there could be a lot of protocols defined in esphome or tasmota and it teaches the necessary protocols for the OB38S003.

Does this sound like somthing doable?

You can essentially send arbitrary timings with the 0xB0 transmit command.
So we've added that feature in the other post.

I think a new discussion will be opened to focus on non-responsive microcontroller "freezing" soon.

[otsoni]

Sending is not the problem here, but receiving. I'm not really sure how many needs this and myself I can use the passthrough firmware really well, but I tought that this might be something to think about. I can try to modify the code to allow dynamic protocol defining, but it will take some time.

[mightymos]

Sending is not the problem here, but receiving. I'm not really sure how many needs this and myself I can use the passthrough firmware really well, but I tought that this might be something to think about. I can try to modify the code to allow dynamic protocol defining, but it will take some time.

I see what you mean, should be possible.
It might just be more feasible to add protocols to the table for storing in flash memory, then recompile.
But this can be labeled an enhancement and considered for the future, it's an interesting idea.

[otsoni]

I think that compiling and flashing new firmware to get support for protocols is kinda difficult. I know that not every Average Joes can use this as it needs flashing the firmware at least once, but it would be more simple to just flash one firmware and keep it there regardless of the used protocols. I try to create something for that after debugging the receiving error