This is a question for the radio experts here. I've been into this for about 2 weeks but slowly starting to hit a wall.
I've captured and analyzed the transmission of the Markisol iFit Spring Pro shades, but somehow fail to successfully replicate the signal. I've attached screenshots of both the original and replicated signal (from my code) + my list of 0's and 1's that I've analyzed by looking at the (very clear) original signal from the Markisol remote. The 433.92MHz modules I use are the kwmobile brand, ordered from Amazon. I'm currently testing them with Arduino Uno (genuine).
Short timing is always 13-16 samples, so with a 44100Hz sampling rate that means about a delay of 340 microseconds. Long timing is always 26-32 samples, so double that length.
Signal always starts with a high of 107 samples and a low of 73 samples.
There is a radio silence of 209 samples at the end of each signal, but also a short HIGH of some kind just before it. I'm not entirely sure of its meaning or how to replicate it.
My transmit code is very simple:
Setting the digital pin as OUTPUT.
DigitalWriting LOW/HIGH with delayMicroseconds() and according to the timings (0 = short LOW, 1 = short HIGH, 00 = long LOW, 11 = long HIGH etc.). I've tested the PORTB commands as well, to eliminate possible latency/lag (and tried reducing the timings too, for that same reason).
Yet, as the attached screenshot reveals, the signal my code sends looks nothing like the original. And as expected, the shades won't react to it. Am I doing something completely wrong here? Should I try to implement some library like VirtualWire or rc-switch? The problem is, they don't seem very compatible with the protocol Markisol uses, so heavy modifications would be in order.
The shades also don't activate if I playback the captured signal via the transmitter. I'm at a loss here, really.
jremington:
Probably an error in the code or wiring.
Possibly, but I've been unable to find any. There's only one data wire from the transmitter and it's connected to the correct digital pin (verified with both a LED and a piezo speaker). Code is at the moment just digitalWrite(TRANSMIT_PIN, HIGH/LOW) with delayMicroseconds() in between. My purpose was to write an actual transmit function to use with the reverse engineered commands, but now it seems I'll have to give up on this project and buy the (very expensive) shade motors from Somfy + TaHoma hub.
My transmitting failure could have something to do with the end of the message (+ radio silence), but I'm not really getting anywhere with it.
Hatux:
Should I try to implement some library like VirtualWire or rc-switch?
I would have tried the receive demo examples that comes with the RcSwitch library first (File>Examples of the IDE).
You can't just send a single command to a 433Mhz receiver.
It needs training bits (to adjust the AGC of the receiver), and two or three actual commands (for verification).
The library takes care of all of that.
Leo..
Wawa:
I would have tried the receive demo examples that comes with the RcSwitch library first (File>Examples of the IDE).
You can't just send a single command to a 433Mhz receiver.
It needs training bits (to adjust the AGC of the receiver), and two or three actual commands (for verification).
That's what I did, but these libraries seem poorly suited for the Markisol shades. They work well for lots of other 433.92MHz devices, though. Copying training bits from an oscillator and repeating commands isn't really an issue. I may very well be wrong here, but writing my own code (and learning a lot in the process!) seemed easier than heavily modifying existing libraries.
I actually managed to get forward with this. By plugging the digital transmitting pin from Arduino directly to a cheapo USB sound card (with a 10K Ohm resistor in between) the signal became very clear and revealed some interesting stuff:
HIGH's and LOW's needed to be inverted (so my 1 is actually a LOW and my 0 is actually a HIGH). I don't know the reason for this, though.
Timings needed to be even more accurate: PORTB commands seem to work better, digitalWrite() has quite some latency.
As expected, everything extra (like writing debug info to serial) needs to be commented out. You can clearly see the high latency it causes but I was already aware of this.
My code now sends a command that seems like a 1:1 copy of the original. I'll get to try it later today or tomorrow.
EDIT: Success! Sure enough, as soon as I powered up Arduino with my new code, shades started rolling down! Now the next step is adding them to my voice commands on TRIGGERcmd and scheduling them with a Raspberry Pi.
And why stop there? When "Away" theme on home alarm is turned on, shades could automatically roll down if it's hot outside - and back up when "Home" theme is activated again. Still need to figure a way to connect an Arduino to Logitech Harmony, though...
Once I clean up and organize the code, I'll post the whole thing!
