Decoding of data from CUL

[Dr. Boris Neubert]

Hi,

I attached a terminal to CUL with firmware 1.07 and listened on the 433 MHz
band with X09. I was able to receive data from a Betty remote control with
CC1100 tranceiver. What is the easiest way of decoding such CC1100 sequences
of r s t u g h back into the transmitted bytes? Could you please point me at
the right C code in the firmware where this is done for already implemented
devices that I can use as an example? Can anyone recommend docs or
literature for the beginner that I am?

Ah yes, I will have to go the way into firmware development for
microcontrollers :-|

Objective (stage 1): establish a one way-communication Betty ---> CUL/PC (a
simple part for sending key strokes on air is already avalaible in the Betty
Boop firmware).

Regards,
Boris

[Rudolf Koenig]

> What is the easiest way of decoding such CC1100 sequences
> of r s t u g h back into the transmitted bytes?

Use "tools/timer /dev/ttyACM0 > file.log" to analyze it. The first
column will denote the Unix timestamps, the last the CUL timestamps
(in usec).
"r,s,t,u" denote rising edges (r+the internal state), and "f,g,h,i" is
the falling edge. The CUL times are always relative to the last rising
edge.

Our firmware (culfw) programs the CUL to use ASK/OOK encoding at
1.2KHz, as FS20/EM/HMS all use this encoding. The cc1101 is capable
for other encodings too, like GSK/MSK, and up to 500KHz. Apart from
ASK/OOK there is the bit encoding, e.g. the manchester code used by
HMS which is different from the FS20/EM codes. After that there is the
parity/checksum issue.

I think this is all not relevant with Betty, as the data is analyzed
in the culfw completely by the MCU. But the cc1101 is capable to send
complete packets (up to 64 bytes), taking care of all the problems
above: using this feature is the way to go in a cc1101 to cc1101
communication. The Betty Boop source, cc1101.pdf and the free SmartRF
Studio from Texas Instruments may help you.

> Could you please point me at

See transceiver.c for FS20/EM/S300 decoding and transceiver_hms.c for
a completely different approach with FS20/EM/S300/HMS decoding.

[Dr. Boris Neubert]

> communication. The Betty Boop source, cc1101.pdf and the free SmartRF
> Studio from Texas Instruments may help you.

one more beginner's question: what development tools do you use for
programming and testing the culfw?

Boris

[Rudolf Koenig]

> one more beginner's question: what development tools do you use for
> programming and testing the culfw?

Nothing special. Just the tools described in the README. For setting
the CC1101 parameters SmartRF Studio is of some help, but in my
opinion reading the CC1101 documentation is better. RF hardware for
measuring the output would be helpful, but I think it is out of my
budget.

[Boris Neubert]

Hi,

I ordered a USF 1000 from ELV (for ultra-sound measurement of fill-level of my
cistern). USF 1000 uses a 868 MHz RF protocol so I might give it a try and
decode it.

Am Samstag, 7. März 2009 schrieb Rudolf Koenig:
> > What is the easiest way of decoding such CC1100 sequences
> > of r s t u g h back into the transmitted bytes?
>
> Use "tools/timer /dev/ttyACM0 > file.log" to analyze it. The first
> column will denote the Unix timestamps, the last the CUL timestamps
> (in usec).
> "r,s,t,u" denote rising edges (r+the internal state), and "f,g,h,i" is
> the falling edge. The CUL times are always relative to the last rising
> edge.

Could you please give some hints what the internal state means?

When I decode the constant stream of air traffic in my house with the aid of
tools/timer, I get sequences of r-g-r-g-r-g interdispersed with ? followed by
a hex byte (second else branch in timer.c) and plain characters (first else
branch). From the notion of X18 in the README it is not clear to me what the
latter two cases signify. Could you please explain?

Assuming the r-g-r-g-r-g sequences are something FS20/FHT-like (in the broader
sense), how can I translate it into byte sequences? The traffic currently
observed are FHT, EM, KS300 and HMS messages. So it should be possible to
practice a bit with the output of the known stuff before decoding the unknown
protocol. I tried to use the source code in culfw's transceiver.c but with no
initial hints about its principles it would take me ages to understand how it
is done.

Regards,
Boris

[Rudolf Koenig]

> Could you please give some hints what the internal state means?

From transceiver.c:

#define STATE_RESET 0
#define STATE_INIT 1
#define STATE_SYNC 2
#define STATE_COLLECT 3
[...]
if(tx_report & REP_MONITOR) {
DC((rf==RISING_EDGE ? 'r' : 'f') + b->state);

> When I decode the constant stream of air traffic in my house with the aid of
> tools/timer, I get sequences of r-g-r-g-r-g interdispersed with ? followed by
> a hex byte

The hex bytes and the ? are printed if the data read from the CUL is
not consistent, in such a case most probably some bytes were lost.
Sometimes one can reconstruct the data from the hex bytes, e.g. when
only the first byte of the telegram ('r'/'g') is lost. Strangely the
USB communication is not very reliable for this purpose, but is
working much better when reading files from the CUR.

> Assuming the r-g-r-g-r-g sequences are something FS20/FHT-like (in the broader
> sense), how can I translate it into byte sequences?

For FS20 decoding it is sufficient to keep only the lines with the
'.' (rising edge). Values below 500 should be interpreted as a 0 bit.
A telegram starts with a lot of (12?) 0 bits, followed by one 1 (start-
bit) and then groups of 9 bits/byte. FHT is essentially the same (with
another crc offset), EM and S300 are also very alike but are using
different parity schemes. HMS encoding is different, you have to look
into transceiver_hms.c for details.

[Rudolf Koenig]

> I can log the datagrams sent by the Velux remote control with culfw and
> timer, e.g. for the down button of shutter #1, I get something like
[...]

I am quite sure that this is not a complete message. There are far too
few bits
(<10), usually beside net data you need sync/parity/checksum. I can
imagine that
reception of 433MHz data with a CUL antenna tuned for 868 is not very
clear.
But if the data is accurate, it might be part of a Manchaster encoded
message,
for which it is typical to have 3 different rising edge times.



> Given the above sequence, what needs to be done to replay the detected
> sequence with (an extended) culfw? I guess that something similar was done
> for the Hoermann garage door opener.

There is still no code to replay Hoermann messages with the CUL (as
far as I
know), but part of the infrastructure is already there. For "sendraw"
you can
specify a buffer of bits to send, and can specify the 0 and 1-bit high/
low
times separately (wait_high_zero, etc). This still won't help you if
you want
to skip the sync or if you need a totally different encoding like
Manchaster.

[KZ]

Any ideas what this output from the CUL is associated with?

p 31 871 1146 7 0 7 50

[Rudolf Koenig]

On Jun 14, 7:21 pm, KZ <andy...@gmail.com> wrote:
> Any ideas what this output from the CUL is associated with?
>
> p 31  871 1146  7  0 7 50

Not much: 871us zero-bit length, 1146 avg length (=> 1 == 1421us), 7
zero bits (sync) followed by 1 (startbit), then further 0 bytes and
7bits (1010000). Then there was no reception for at least 7.3ms. The
state machine for rising edge was in state 3 (STATE_COLLECT, received
sync and startbit), the state machine for falling edge was in 1
(STATE_INIT, one valid "bit" received). Most probably an short message
from something like an FS20. Do you receive these bits all the time?

[A.Plowman]

Thanks for the interpretation of the data.  I'm hoping that it is from an Oregon Scientific remote temperature sensor. 

Someone who has built their own receiver for a similar sensor has posted this information, which seems to fit with your interpretation: (http://www.alyer.frihost.net/thn128decoding.htm)

The relevant part:

"- Preamble (this part consist no useful information and used for RF receiver tuning);
- Synchronization bits;
- Three information's bytes;
- One byte of CRC;

The bytes are sending in reverse order and they are coded in a Manchester-type manner. I think that explanations given at Figure 1 are well enough for understanding that

 Next step is the determination what the information each bit is carry on.

First of all let's write the received bits in a normal binary mode.

So we have:
 - Byte #1: 00100011;
 - Byte #2: 01110000;
 - Byte #3: 00000001;
 - Byte #4 (CRC): 10010100.

[Matthias Urlichs]

Hi,

A.Plowman:

> Thanks for the interpretation of the data. I'm hoping that it is from an
> Oregon Scientific remote temperature sensor.
>

That sounds abut right.

> The bytes are sending in reverse order and they are coded in a
> Manchester-type manner.

Unfortunately, CUL doesn't do Manchester yet. Somebody needs to
implement that in the receiver. I've sketched an implementation
some time ago, but I have no way to test that, so somebody else
needs to do the work. :-P

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
v4sw7$Yhw6+8ln7ma7u7L!wl7DUi2e6t3TMWb8HAGen6g3a4s6Mr1p-3/-6 hackerkey.com
- -
This fortune is encrypted -- get your decoder rings ready!

[Rudolf Koenig]

> Unfortunately, CUL doesn't do Manchester yet. Somebody needs to
> implement that in the receiver. I've sketched an implementation
> some time ago, but I have no way to test that, so somebody else
> needs to do the work. :-P

MM sent me an alternative RF parser based on TOSTi's work, which can
decode HMS (==Manchester), it is checked in as transceiver_hms.c
Unfortunately it breaks some other features already used, so it is not
the default yet. But It is on my CUL-TODO list.

[Markus Voss]

Very interesting project - please keep us posted on progress.

Thx,
Markus.

[Maz Rashid]

Hi Boris,

 

just for the case you get the decoding with CUL working.

Here some info about the message sent from UFS:

http://www.ip-symcon.de/forum/f23/einbindung-usf-1000e-ip-symcon-6430/

 

According the above discussion, the FHZ-1300 PC is able to decode the UFS-Stream.

 

 

BTW:

I am personally working on a system based upon this (http://www.ip-symcon.de/forum/f16/wasserstand-messen-1-wire-5487/)

(forget about the elektonik setup and the parts named there, focus on the idea)

I will use a CPM from busware and send the fill-status as a S300TH-Sensor.

 

cu

Maz

[TOSTi]

UFS mit CUL aktuelle culfw:

'gen Himmel:

FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB7FF
FA5CEAAB74B
FA5CEAAB717

ganz nah:
FA5CEAAB70F
FA5CEAAB70B
FA5CEAAB705
FA5CEAAB706
FA5CEAAB705

an die Decke:

FA5CEAAB76A
FA5CEAAB76C
FA5CEAAB7FF
FA5CEAAB7FF

Also ganz normales FS20 im letzen Byte steckt die Entfernung.
Housecode und ID hat sich bei mir nicht geändert (trotz mehrfacher
Batterieausbauten)

Sollte also problemlos ins fhem passen ...

[Boris Neubert]

Hi Maz and Dirk,

Am Montag, 15. Juni 2009 schrieb TOSTi:
> UFS mit CUL aktuelle culfw:

...

> Also ganz normales FS20 im letzen Byte steckt die Entfernung.
> Housecode und ID hat sich bei mir nicht geändert (trotz mehrfacher
> Batterieausbauten)

great! This saves us a real lot of time.

Hopefully the postman will deliver my USF 1000 device by Saturday. Then I will
give it a try with FHZ1300 and/or CUL. I will check in what ways the
datagrams differ from those from Dirk's tests and those listed in the forum
posts Maz hinted us to. As I have some empty batteries by chance, I can
probably even find out how the battery-low signal is transferred. The FHEM
module will then easily be written!

Stay tuned!

Regards,
Boris

[A.Plowman]

Would it be possible to share the alternate parser?  I don't need the other features. 

[TOSTi]

On 20 Jun., 01:52, "A.Plowman" <andy...@gmail.com> wrote:
> Would it be possible to share the alternate parser?  I don't need the other
> features.

ELFE.hex (32.16 Kb) - an ELV devices airtraffic (868MHz AM) decoder
(FS20,FHT,EM,KS,HMS-protocols):
http://busware.de/tiki-download_file.php?fileId=3

The source is here, called "DecoderTest":
http://busware.de/tiki-download_file.php?fileId=6

[MM]

On Fri, Jun 19, 2009 at 07:52:35PM -0400, A.Plowman wrote:
> Would it be possible to share the alternate parser? I don't need the other
> features.

It's in the CUL cvs. You just need to edit the makefile to compile my
parser instead of the default one.

bye
MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[A.Plowman]

Thanks!

2009/6/19 TOSTi <tost...@gmail.com>