• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


3T-Motors 434Mhz senders / receivers
#31
Add print statements everywhere to show you what it's doing, and where it's going wrong Smile
 
Reply
#32
Hi pilino,

I did further testing.
This is the current status of the send part of the protocol:
- the full pulse sequence has always the correct length (O.K.)
- high / low pulse patterns are generated correctly in principle (O.K.)
- header and footer are always generated correctly (O.K.)
- the system ID is generated correctly (O.K.)
- the UP (-t) and DOWN (-f) commands work as required (O.K.)

BUT: the generation of the unit number is not consistent.
Please see the examples below:

CORRECT unit:
sudo pilight-send -p 3TMotors_screen -i 138676505 -u 0 -f
5270 1240 620 310 310 620 310 620 310 620 310 620 620 310 310 620 310 620 310 620 620 310 310 620 310 620 310 620 310 620 310 620 310 620 620 310 310 620 310 620 620 310 310 620 310 620 310 620 620 310 620 310 310 620 310 620 620 310 310 620 310 620 310 620 310 620 310 620 310 620 620 310 620 310 310 620 310 620 620 310 620 10540

WRONG unit:
sudo pilight-send -p 3TMotors_screen -i 138676505 -u 3 -f
5270 1240 620 310 310 620 310 620 310 620 310 620 620 310 310 620 310 620 310 620 620 310 310 620 310 620 310 620 310 620 310 620 310 620 620 310 310 620 310 620 620 310 310 620 310 620 310 620 620 310 620 310 310 620 310 620 620 310 620 310 620 310 310 620 310 620 310 620 310 620 620 310 620 310 310 620 310 620 620 310 620 10540

CORRECT unit:
sudo pilight-send -p 3TMotors_screen -i 138676505 -u 15 -f
5270 1240 620 310 310 620 310 620 310 620 310 620 620 310 310 620 310 620 310 620 620 310 310 620 310 620 310 620 310 620 310 620 310 620 620 310 310 620 310 620 620 310 310 620 310 620 310 620 620 310 620 310 310 620 310 620 620 310 620 310 620 310 620 310 620 310 310 620 310 620 620 310 620 310 310 620 310 620 620 310 620 10540

There is a bug in the create unit code section.
For instance:
for unit 1, 2, 3 and 4 wrong binaries are generated.
unit 1 should be 0001, but the generated code is 1000
unit 2 should be 0010, but the generated code is 1000
unit 3 should be 0011, but the generated code is 1100
unit 4 should be 0100, but the generated code is 1010

Surprisingly: the generated codes for unit 0, 14 and 15 are correct.
I am not a programmer, so my debugging is not really scientific...
 
Reply
#33
Is there a chance to get a hint what failure I made in the create unit code of this protocol? After detecting the failure I am open to correct the protocol and do additional follow-up testing. Smile
 
Reply
#34
What's the range of possible IDs? Did you test all of them, and it's only 1, 2, 3, and 4 which create incorrect codes?

Also, can you point me to your current code please so I can have a look?
 
Reply
#35
Hi pilino,

thanks for your quick reply!

My current protocol code is attached in post 22 of this thread.
For the unit code values from 0 to 15 are allowed. Please note that unit code 0 triggers all devices.
I tested only ~half of this unit code range.
When I send out the unit codes in raw mode "handwritten" everything works well.

Please let me know if you need additional input from my side to push the protocol development forward.
 
Reply
#36
I have spent some additional time to find the bug in the protocol. Without success.
With some small help from experienced protocol developers I think that this work can be completed.
I would be glad to perform extensive testing of the bug-free protocol.Smile
 
Reply
#37
@tomhai,
The problem is with your code in
void 3tmotorsSrCreateId(int id) { ... } and
void 3tmotorsSrCreateUnit(int unit) { ... }

You got a PM as requested.

@curlymo
In addition i do assume that tomhai's following assumption is wrong: the protocol has a header value of 5270 and a footer value of 10540.
I do assume that the protocol starts with the header pulses 10540 5270 followed by data and that there is no footer value.
I will work with tomhai on that topic and verify whether my assumption is correct or not.
 
Reply
#38
Yes, thanks!
 
Reply
#39
I posted some visual analysis of my rolling shutters protocol which seems to be similar ti the 3t protocol.

Check it out here
 
Reply
#40
Hello Tomhai,

i have also some 3t shutter motors.

Have you fixed all problems? Can you post your whole realisation?

I also want to run my shutters with my pi and ifttt.  

THX
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  Rohrmotor24 receivers protocol TRIROG 6 3,215 03-18-2016, 08:29 AM
Last Post: TRIROG

Forum Jump:


Browsing: 1 Guest(s)