unleashed-firmware
unleashed-firmware copied to clipboard
DarkFlippers
Wrong Came Atomo button counter sequence during sending from Flipper
Describe the bug.
Version: Unleashed dev branch, commit 462ab255
During continuous sending Came Atomo, button counter changes from ~ 0x4Ch to 0x54h Remote is working, gates opening but: To program new remote to receiver with the old one, button counter should tick from 1 to 127 and begin from 0 with the same Pcl_Cnt. After this "zero-cross event" the receiver should switch to programming mode.
Reproduction
Select Menu => Sub-GHz => Saved => select any Came Atomo remote => Emulate Hold central button to continuous send Pcl_Cnt is static Btn_Cnt is changing from ~ 0x4Ch to 0x54h (instead of changing from 0x0h to 0x7Fh and begin from 0x0h with the same Pcl_Cnt)
Target
No response
Logs
No response
Anything else?
No response
Hello! Can you share full RAW recording of the original remote so i can check btn counter?
I'll send it later. The original remote is at my home now. I checked the counters with my second Flipper.
There is RAW record from the original fob in attach. (.sub renamed to .txt) Came_Atomo_RAW-2024_11_08-21_29_01.txt
There is RAW record from the original fob in attach. (.sub renamed to .txt) Came_Atomo_RAW-2024_11_08-21_29_01.txt
Thx, will work on that issue next days
Yes, the issue is present, its possible to generate full sequence but it will take big buffer space and will require long button hold, since current implementation in subghz doesnt actually support sending different codes while holding a button, so for system like that - we generate full or partial sequence and put it all in buffer, while button is held it being transmitted as it was one code (but big one) To fix this condition there are three ways i see, 1 - generate whole 127 codes and put them all in buffer (we may have not enough ram for that) (and zero cross event wont happen if you release button too early) 2 - start all parcels from zero? should be already done, may be not resetting properly, will check later 3 - use only specific limited number of values to trick receiver that it had got all signals but missed some in between (like skip big parts of the counter, send sequence like 0 5 20 40 50 90 100 0)
I think third way is the best solution. Also I would try something like "10,50,100,125,126,127,0,1,2"
I think third way is the best solution. Also I would try something like "10,50,100,125,126,127,0,1,2"
Ill make some changes after release in next dev builds, and will ask you to test, thats fine?
oh actually, it will be in next dev build, any build after 1093, i just pushed that in dev, please test when possible
https://t.me/kotnehleb/3387
link to the latest current build that contains required fixes, ready for test
Sorry for late answer. I finally got to my gates. Unfortunately could not reproduce the original remote's function with Flipper.
First iteration, counter goes 0-127 first time - the gates are opening Second iteration, counter goes 0-127 second time - trying to add new remote - no reaction from controller, the gates remain open till timeout. Third iteration, counter goes 0-127 third (and more) time - the gates are closing and that's all. ;-(
Sorry for late answer. I finally got to my gates. Unfortunately could not reproduce the original remote's function with Flipper.
First iteration, counter goes 0-127 first time - the gates are opening Second iteration, counter goes 0-127 second time - trying to add new remote - no reaction from controller, the gates remain open till timeout. Third iteration, counter goes 0-127 third (and more) time - the gates are closing and that's all. ;-(
Currently we are generating this sequence of button counter 10 50 125 126 127 0 1 2
so for receiver it will look like whole cycle with some missing parts which it should accept, i can make a build with different sequence, if you have any ideas but otherwise i have no way to test it or verify, need to have receiver board to try it, which i don't have
Found it
switch(i) { case 0: pack[0] = 10; // 0A break; case 1: pack[0] = 30; break; case 2: pack[0] = 125; // 7D break; ...
I've purchased Came receiver module for local tests and will play with it at home.
Found it
switch(i) { case 0: pack[0] = 10; // 0A break; case 1: pack[0] = 30; break; case 2: pack[0] = 125; // 7D break; ...I've purchased Came receiver module for local tests and will play with it at home.
I'm searching one now, gonna order it too, to test various cases myself
Got the RE432M Came's receiver and it works! Sending Came Atomo code from Flipper about 9-10 seconds triggers "programming" mode at the receiver. There is something wrong with my gates. "Clean" receiver triggers Ok.
Got the RE432M Came's receiver and it works! Sending Came Atomo code from Flipper about 9-10 seconds triggers "programming" mode at the receiver. There is something wrong with my gates. "Clean" receiver triggers Ok.
Thats great news, but actually im waiting for same receiver to arrive, so ill verify all modes maybe there's a need for small tweaks
Idk what to do later with that stuff, maybe make motorised toilet door, or miniature boom barrier xd
@RekordNadoev hello I've got the receiver and tested all various cases, flipper emulation or original remote may not work if button is held not enough, also its not very stable if antenna is a piece of wire connected to receiver, so its worth it to check your gates receiver box, maybe cable got disconnected or it had no proper antenna in the first place, This actually may cause described issue
As for the programming mode it works pretty well, both from original remote, or copy of the original remote on flipper, or new remote on flipper that was bound manually to the receiver before via button
I made updated documentation on how to bind those type of remotes, https://github.com/DarkFlippers/unleashed-firmware/blob/dev/documentation/SubGHzRemoteProg.md
Check it out, if you find any more details on this issue except possible antenna disconnect, reopen or create new one, thx
Also I noticed one thing, if power supply is noisy, no matter how well it outputs power, receiver is taking max 30mA as i found If theres noise in powerline it will not work with atomo remotes at all, or will work very bad, like 1 from 5 tries So, receiver is very sensitive to incoming power, i tested with 12v regular transformer>diode bridge>filtering caps type supply it worked very well, then tried 12v upstep converter from 3.7v battery, it worked only with static came remotes, for some reason, atomo was not working at all, thats strange but maybe will be useful for someone in future who may face some issue with that receivers