Description

Possibility to, via software, set TellStick Duo in "promiscuous" mode, where it just filters out garbage, but all that could be valid signals are sent on to the computer. This would allow TellStick Duo owners to participate in adding support for more protocols.

I tested something like this to add support for a new protocol (with a modified fineoffset file). I added some extra data outpout for similar bit counts, which helped me to spot patterns of the lengths of the encoding. The code is currently very experimental, so I'm not sure if it tells what's happening that well, but the basic approach was to have some durations of 0-strings and 1-strings (bits of contiguous ones and zeros) as extra debug data in the "data" hex string. (the commented-out DATA_LENGTH*3 at the end), which are then passed to the host. The way this is done with the experimental code requires also changing telldus-core, instead could perhaps have a separate mode where user could subscribe to protocol-specific or generic extra data arrays.

The problem is recognizing what's garbage and what's interesting. Kind of a chicken-and-egg problem - if we do have no idea of the protocol, we can't easily know where the noise ends and signal starts.

What helps is that the radio traffic sets some boundaries - sending zeros and ones directly won't produce good results on the radio channel, so there's some kind of coding. Looks like using pulses with width coding is one common approach, used e.g. in the fineoffset protocol one pulse length signifies a zero, another signifies a one. Manchester encoding is another.

One common approach to grokking 433Mhz signals seems to be visualizing the signal, by connecting the amplitude output of a radio receiver to an oscilloscope, or, for people without a scope, to a computer sound card with suitable software (like Audacity) working as an oscilloscope. This may allow recognizing different radio sources by the amplitude. But this probably can't be done with the Tellstick (nicely anyway, without breaking the case anyway - probably can't be done without tapping to the hardware if even then, and Micke.Prag tells us that if the Duo is opened it can't be put back together, no screws apparently)

Thinking of how to try to grok protocols with the Tellstick, outputting the reception transitions from one to zero and zero to one by lengths helped to recognize the protocol which the code above reads (see http://www.telldus.se/forum/viewtopic.php?f=12&t=3086&sid=2ab0b664faceaf92a4ef8a951c6c8229 ). With some suitable computer-side software, this too could be visualized, helping to recognize the start of a packet and end of a packet, and get some idea if the signal is pulse width modulation, Manchester coding or something else.

If the packets have enough repetition (like probably most devices which send data do), it would allow for start and stop patterns to be set, or alternatively just the start pattern, and then a bit count.

So, for firmware to help debug unknown protocols, one approach would be two phases

1) add promiscuous mode to firmware: transmit everything to the computer, e.g. as zero string / one string lengths. Allow some way of the data to be represented textually and visually to help try to find how a packet start can be recognized

2) add triggered recording of a packet to firmware: a command specifies the start packet trigger bit pattern, and then alternatively either a packet size (in bits or bit transitions), or an end pattern. Then only packets matching the trigger (filter) are sent to the computer

Seems that in practice, at least with pulse width encoding, start packet would need to be specified with a pulse pattern with upper & lower bounds for each pulse length.

Might be easier to recognize a packet ending, so a trigger / filter with a packet ending described by bit transition lengths and a packet size would also be useful.

For the generic goal of allowing the Duo to receive new protocols, one approach would be to change the firmware radio reception architecture a bit, so the firmware wouldn't need to know the higher-level protocol details (e.g. packet lengths) of each device like it does now, but the higher level would be handled at telldus-core.

What I'm thinking of is that the computer would tell the firmware something like "I want to listen to PWM-encoded signals with pulse lengths between 28 and 34 for ones and 14 and 18 for zeros, with packet size between 10 and 20 and start & end described here." The firmware would then blink the leds & send the computer/router/whatever only the data which the user wants to subscribe to. This would cut down on spurious blinkenlichts and unnecessary traffic between Tellstick & host (like neigbour's sensors), and make things easier to grok for the end user. Telldus-core could of course also have a "full listen" mode so the user could look at all the data available to find out what are the wanted sensors, but the normal mode of operation would not list everything. With things set up like this, adding support e.g. for a rain or wind sensor might not require a new firmware, just an upgrade to telldus-core, if the low-level encoding is one already supported by the firmware.

No, no proof of concept yet at least. The current firmware code I have is below as a diff, just addition of optional debug data (TIMINGS) and listening of all packets (PROMISCOUS), not even sure if that currently works for PROMISCUOUS. It does work with TIMINGS for the "Nexus" sensor (though currently requires a modified fineoffset file in telldus-core).

To move forward, could be a good idea to define the commands to modify the settings of the firmware. Protocol seems to be commands are single chars, so how about O command for Options, and parameter R for reception? Then perhaps something like:

Most commonly used PWM / Manchester / whatever formats could possibly be at first hard-coded in the firmware (for best performance), maybe later add support for custom encodings something like:

ORFP50=20-30/10-15,10-30 - set custom pulse width encoding #50, where length of ones is between 20-30 time units, length of zeros is 10-15 time units, and packet length is between 10 and 30 bytes.
ORFP51=20-30/10-150000,FFFF - set custom pulse width encoding #50, where length of ones is between 20-30 time units, length of zeros is 10-15 time units, any packet length,packet starting pattern 0000, packet ending pattern FFFF
ORFP51=20-30/10-15PT1,PT2 - set custom pulse width encoding #50, where length of ones is between 20-30 time units, length of zeros is 10-15 time units, any packet length,packet starting pattern #1, packet ending pattern #2 (allowing for starting patterns not part of data but encoded as out-of band bit patterns)

For the timings / raw pulse length debug output (TIMINGS code), instead of piggybacking the debug data after the "data" field, would make more sense to add a new field, "lengths", "raw", "rawpulses", or whatever would be understandable.