01-17-2014, 03:42 PM
Can you post the full concept of this protocol somewhere?
QUIGG (Globaltronics/ALDI)
|
conrad_rsl_switch->pulse = 2;
conradRSLSwParseBinary: 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
conrad_rsl_switch->pulse = 4;
conrad_rsl_switch->rawlen = 50;
conrad_rsl_switch->lsb = 2;
conrad_rsl_switch->binlen = 12;
(06-11-2014, 10:46 PM)RinusW Wrote: I own several Quiqq switches of the type GT-7008AS ....This is correct, my original assumption was wrong that the id field is only covering 0....31. Please use the version that comes with pilight V5. Although this version won't dimm the 7008AS, this requires the latest release from the development branch.
At first this seemed to work, i.e. the default value id=12 worked well with the 4 different unit codes. But when I tried other id values, it was quite obvious that for some id values the implemented protocol didn't work at all.
...
(06-11-2014, 10:46 PM)RinusW Wrote: So I started with my receiver module, coupled to my digital scope, looking at the pulses that came out of the receiver. The first thing I noticed is that the pulse width varies somewhat, and that the short pulses usually are somewhat shorter than the 700 us used in the current protocol implementation.The problem you decribe is related to the short footer length, which is only 4000µS with the pilight driver you use. For the learning mode of the switches, the footer length has to be at least twice as long. The actual pulse duration for a short pulse can vary between appr. 620µS and 950µS. The current release uses 700µS and 1400µS and for sending of data a footer length of 23000µS (the GT-7000 uses 81192µS).
And that the long pulses clearly are longer than the 1200 us. Based on my measurements I decided to use a short pulse width of 680 us and a long one of 1320 us. The ratio therefore is closer to 2:1 than in the current implementation. But this alone didn't solve the problems controlling the switches.
(06-11-2014, 10:46 PM)RinusW Wrote: As second step I decided to investigate the meaning of the bits in the protocol frame a bit further. Although the frame construction seems as described in the previous posting (a very good job, btw), the meaning of too many bits stayed unexplained. .......I am currently in a discussion with curlymo on what should be included in the protocol driver and what should not. The GT-7008AS seems to work a bit different than other devices, i am guessing here a little bit, as i am waiting for a GT-7008AS to be shipped as a spare part and i have engineered the protocol from the GT-7000 handheld transmitter, but i am sure that my interpretation is quite right.
(06-11-2014, 10:46 PM)RinusW Wrote: The first 12 bits form in fact a single device-id field, and the last bit of these 12 bits is an odd parity bit over the whole id field. So actually, the switches recognize 11 active bits for the id, giving the id a range from 0 to 2047. And this explains why some id's simply didn't work. The parity over the id field was not correct and probably therefore the overall parity was not either.You are correct, the parity bit covers Bit 13 to 19 only, but in my logic it is an even Parity Bit.
(06-11-2014, 10:46 PM)RinusW Wrote: So, the next step is a protocol implementation based on these findings. ....The development version of the quigg_switch protocol V5 is updated and available from the git repository.
(06-11-2014, 10:46 PM)RinusW Wrote: Especially the first bit always is 1, the next 5 bits contains the id, the next 5 bits are always 0, and the last bit of the id-field is the odd parity bit.The GT-7000 is using the other bits as well, it just takes some time to get to that point, just press the "Neuer Code" button for 1 minute or 2..... and it uses it as one bit block.
(06-11-2014, 11:01 PM)curlymo Wrote: Yes, please post it, so i can release it as a module and wo_rasp can have a look at it as well.Please see my previous posting.
pilight-send -p quigg_raw -c "0 11111 10010 0 00 01000"
pilight-send -p quigg_7008 -i 1010 -u 0 -t -m 1
(06-12-2014, 12:29 AM)wo_rasp Wrote: Please use the version that comes with pilight V5. Although this version won't dimm the 7008AS, this requires the latest release from the development branch.Yes, I should update my repository on a regular base. But I didn't, so I'm talking about V4.
(06-12-2014, 12:29 AM)wo_rasp Wrote: The problem you describe is related to the short footer length, which is only 4000µS with the pilight driver you use. For the learning mode of the switches, the footer length has to be at least twice as long. The actual pulse duration for a short pulse can vary between appr. 620µS and 950µS. The current release uses 700µS and 1400µS and for sending of data a footer length of 23000µS (the GT-7000 uses 81192µS).Sorry, I forgot to say that I was looking at the pulses produced by the remote control unit and not by the sender of pilight. Some other numbers measured with my scope: the pulse sequence has a duration of 41,5 ms and a repetition time of 122,5 ms, which means that the footer is 81 ms. Since the pulse sequence always has 21 short and 20 long pulses, and when we assume that a long pulse is twice as width as a short pulse, the duration of 61 short pulses therefore is equal to 41,5 ms. This gives 680,3 us for a short pulse and 1360,7 us for a long pulse. But probably 700 and 1400 us will work fine too.
(06-12-2014, 12:29 AM)wo_rasp Wrote: You are correct, the parity bit covers Bit 13 to 19 only, but in my logic it is an even Parity Bit.If you agree that bit 1..11 are the actual device-id bits and bit 12 is an odd-parity bit over the bits 1..12 (i.e. the device-id bits) then it is correct that the last bit (bit 20) is an even parity bit over bits 13..20. And since bits 1..12 have an odd parity, this is the same as saying that bit 20 is an odd parity bit over all bits 1..20.
I will check into the odd parity bit issue, as my GT-FSi-04a will work without parity bit and the GT-7000 handheld seems to use al 12 bits as an id. Your finding with the Gray code is correct.
(06-12-2014, 12:29 AM)wo_rasp Wrote: I have a question regarding the fifth button row.I didn't study the function of the so-called dim key, and I didn't implement any special functionality in my 7008 protocol either, because the GT-7008AS switch doesn't have a dim function, and doesn't react when pressing this key. And according to the manual mentioned earlier the GT-FSI-4a should not either.
I have called it dimm, as it seems to implement the dimm functionality and is always active for the last switch-unit used, i.e. if you turned unit 2 on the dimm button will send pulses to unit 2 to be interpreted as either
"dimm-down" or "dimm-up".
The current version of the quigg_switch protocol driver does not remember which unit was used last, thus you need to add the unit when using the dimm functionality (In opposite to the GT-7000, with pilight you do not need to send a turn on/off command first before using the dimm button).
(06-12-2014, 12:29 AM)wo_rasp Wrote: The GT-7000 is using the other bits as well, it just takes some time to get to that point, just press the "Neuer Code" button for 1 minute or 2..... and it uses it as one bit block.I agree that the mode parameter isn't needed. I will remove it from my implementation and use only the 11 bit id-addressing format.
(06-12-2014, 12:29 AM)wo_rasp Wrote: I am really struggling with the footerlength issue we have discussed so far, can you please have a brief review on my latest pull request and give me a hint what i am not doing right with regards to adding additional pulses. In principle the code works, but reaction time is sluggish.My measurements showed that the remote control GT-7000 repeats the command only after 122 ms. This is a repetition frequency of 8 per second. 4 pulses is then equal to 500 ms.
The problem i currently face is the fact that a real switch will react within 4 pulses, whereas pilight requires at least a pulse stream of 500mS or more.
Possibly Related Threads... | |||||
Thread | Author | Replies | Views | Last Post | |
Quigg GT-1000 | maartenh | 55 | 52,451 |
07-28-2020, 03:21 PM Last Post: pgScorpio |
|
QUIGG GT9000 (Globaltronics/ALDI) | NeoFlo | 140 | 132,444 |
01-07-2020, 04:03 PM Last Post: aP7D1CKD |
|
[Solved] Quigg GT-1000 leaving transmitter ON | VrahoK | 11 | 4,743 |
12-22-2019, 12:17 AM Last Post: VrahoK |
|
Brennenstuhl RCR CE1 1011 with QUIGG GT9000 Protocol | scootermacro | 1 | 2,028 |
06-27-2019, 06:20 PM Last Post: scootermacro |
|
Weather Station Globaltronics GT-WT-01 | Prutsky | 13 | 14,446 |
04-09-2018, 07:34 PM Last Post: NevelS |
|
quigg gt7000 Dimmer | wchristi | 11 | 13,808 |
04-30-2015, 09:25 AM Last Post: wo_rasp |
|
Quigg Screens | curlymo | 6 | 7,507 |
01-31-2015, 07:33 PM Last Post: curlymo |