I receive data, but it doesn't make sense - SOLVED

[docbee]

Hi,
I am brand new to the rfxcom and do have a problem in getting it to read out my oregon weather sensors.

1. I am working on linux (old 2.4.20 kernel)

2. the rfxcom device seems to be properly addressed at /dev/ttyUSB0

3. I set the transfer protocol to 4800 baud, no parity, 1 stop bit.
Here are the details:
# stty -a < /dev/ttyUSB0
speed 4800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

4. When I listen at<font face="Courier New"></font id="Courier New"> /dev/ttyUSB0 I get a stream of data that looks like this. Unfortunately this doesn't match with any of the rfxcom docu for the oregon sensors. Here is a part from the data stream:
<font face="Courier New">000007a0 0c fc 00 08 3c cc 1c cf 3c cc 1c cf 3c cc 1c cf |.ü..<Ì.Ï<Ì.Ï<Ì.Ï|
000007b0 28 d8 1a 23 14 e4 19 c2 14 e4 19 c2 54 a4 20 24 |(Ø.#.ä.Â.ä.ÂT#164; $|
000007c0 54 a4 20 24 3c cc 1c cf 3c cc 1c cf 3c cc 1c cf |T#164; $<Ì.Ï<Ì.Ï<Ì.Ï|
000007d0 3c cc 1c cf 28 d8 1a 23 0c fc 00 08 0c fc 00 08 |<Ì.Ï(Ø.#.ü...ü..|
000007e0 14 e4 19 c2 14 e4 19 c2 3c cc 1c cf 54 a4 20 24 |.ä.Â.ä.Â<Ì.ÏT#164; $|
000007f0 3c cc 1c cf 3c cc 1c cf 28 d8 1a 23 28 d8 1a 23 |<Ì.Ï<Ì.Ï(Ø.#(Ø.#|
00000800 0c fc 00 08 0c fc 00 08 14 e4 19 c2 14 e4 19 c2 |.ü...ü...ä.Â.ä.Â|
00000810 3c cc 1c cf 3c cc 1c cf 3c cc 1c cf 54 a4 20 06 |<Ì.Ï<Ì.Ï<Ì.ÏT#164; .|
00000820 54 a4 20 06 28 d8 1a 23 28 d8 1a 23 14 e4 19 c2 |T#164; .(Ø.#(Ø.#.ä.Â|
00000830 14 e4 19 c2 0c fc 00 08 0c fc 00 08 3c cc 1c cf |.ä.Â.ü...ü..<Ì.Ï|
00000840 3c cc 1c cf 3c cc 1c cf 3c cc 1c cf 54 a4 20 06 |<Ì.Ï<Ì.Ï<Ì.ÏT#164; .|
00000850 54 a4 20 06 28 d8 1a 23 28 d8 1a 23 14 e4 19 c2 |T#164; .(Ø.#(Ø.#.ä.Â|
00000860 14 e4 19 c2 0c fc 00 08 3c cc 1c cf 3c cc 1c cf |.ä.Â.ü..<Ì.Ï<Ì.Ï|
</font id="Courier New">
5. When I try to send a command like F02A to the rfxcom, I don't get any reply or change in behaviour: echo "F02A" > /dev/ttyUSB0

Any ideas what goes wrong here?

Regards,
Boris

[Willem4ever]

Could be a baudrate problem, try using 38400 baud instead and see if you can initialize the device. Alternatively use the VB application that comes with the receiver if you are in possesion of a windoze box.

[b_weijenberg]

The receivers are set to 4800bd when delivered.
Best is to check the receiver first with the RFreceiver program to be sure all works OK.

Bert

[Snelvuur]

http://wiki.binkey.nl/SVN

Do what it says there, then try the xpl-rfxcom package with -v and /dev/ttyUSB0. You should at least get humidity and temperature back. If that works at least you know that the connection is working as it should.

Do note that most is still experimental since support for linux (perl) has just been released.

And check with dmesg, that you have the correct version for the usb driver once you insert it. I had to upgrade my kernel (i'am using 2.6.18)

[docbee]

Many thanks to Bert who gave me the hint to install .net framework 3.0 on my windows machine. Having that I could start RFreceiver and after switching to "variable length mode" I can see all the weather data coming in. GREAT!

My problems with linux look like the ftdi module included into my kernel (2.4.20) is an old one that is only good for reading data (ftdi website says kernel: 2.4.20 works for reading, 2.6.9 has read and write corretcly implemented). So it is quite logical that any attempt to say the rfxcom to switch its mode is not working with my old linux box. So I made use of RFreceiver to switch to the desired mode and now I can use the "correctly initialized" rfxcom with my linux box to read out the data.

This time the data looks very good and is compiant with the oregon doc. Here we go...
<font face="Courier New">00000000 50 1a 2d 10 94 80 26 50 83 3e 4c 50 1a 2d 10 94 |P.-...&P.>LP.-..|
00000010 80 26 50 83 3e 4c 58 3a 0d 00 4a 90 05 20 60 01 |.&P.>LX:..J.. `.|
00000020 35 38 50 1a 3d 10 ae 02 26 00 82 3e 31 50 1a 3d |58P.=.®.&..>1P.=|
00000030 10 ae 02 26 00 82 3e 31 50 1a 3d 10 ae 02 26 00 |.®.&..>1P.=.®.&.|
00000040 82 3e 31 60 5a 6d 00 5a 30 26 50 83 9d 31 5c 77 |.>1`Zm.Z0&P..1\w|
00000050 60 5a 6d 00 5a 30 26 50 83 9d 31 5c 77 50 1a 2d |`Zm.Z0&P..1\wP.-|
00000060 20 8b 80 31 40 82 3f 83 58 3a 0d 00 4a 90 04 20 | ..1@.?.X:..J.. |
00000070 60 01 34 5f 50 0a 4d 10 06 70 25 00 00 26 00 50 |`.4_P.M..p%..&.P|
00000080 0a 4d 10 06 70 25 00 00 26 00 58 3a 0d 00 4a 20 |.M..p%..&.X:..J |
00000090 06 22 80 01 33 bb 54 2a 1d 00 b6 00 00 36 52 21 |."..3»T*..¶..6R!|
000000a0 c3 12 54 2a 1d 00 b6 00 00 36 52 21 c3 12 50 1a |Ã.T*..¶..6R!Ã.P.|
000000b0 2d 10 94 80 26 50 83 3e 4c 50 1a 2d 10 94 80 26 |-...&P.>LP.-...&|
000000c0 50 83 3e 4c 50 1a 3d 10 ae 02 26 00 82 3e 31 50 |P.>LP.=.®.&..>1P|
000000d0 1a 3d 10 ae 02 26 00 82 3e 31 50 1a 3d 10 ae 02 |.=.®.&..>1P.=.®.|
000000e0 26 00 82 3e 31 50 1a 3d 10 ae 02 26 00 82 3e 31 |&..>1P.=.®.&..>1|
</font id="Courier New">

[Snelvuur]

If you make anything for linux let us know.. so far only xpl-perl has support for the rfxcom (unless you want to adapt the w800 drivers, but they dont do the full bit length)

[b_weijenberg]

Boris,

That was a fast BBQ!
Is it possible to install the newer FTDI drivers?
http://www.ftdichip.com/Drivers/VCP.htm

It is not necessary to send data again to the receiver. If the receiver is set to a mode it is saved in non-volatile memory. After power down it will restore the correct mode.

Bert

[b_weijenberg]

Check here to find info about RFXCOM and Linux http://www.touteladomotique.com/forum/s ... de=results

[Snelvuur]

That refers to http://www.zoxx.net/~ludo/rfxcom.txt , which on its own its not yet a program compared to the xpl-rfxcom. Its a start though, if you check my earlier posts you can see i got the first code from that french site. Maybe its nice to point to the xpl-rfxcom package to get more support for linux.

[lfrancois]

Yes this code is only some tests to understand how work the RFXCom and get informations from my oregon v2 sensors and from some RF-X10 devices.

So far I get some output but nothing really working.

By the way I have some questions for you, maybe you could reply me, an d help me to develop this script:

There is a 32 bits mode and a 48 bits mode, in which case do we need to choose the 32 or the 48 bits?

In the small code above, when I do a bytesPrint, I have some results amazing, and I don't yet understand why.

[b_weijenberg]

The Variable Mode (formerly called 48bit) must be used.

The 32 bit mode can be used for existing software that supports the W800. The RFXCOM receiver operates in 32 bits mode like a W800 and the receiving possibilities are limited to X10 lighting, X10 security and the RFXSensor.
When the RF modes are enabled, the RFXCOM receiver also converts:
- ARC-Tech (KlikOn-KlikOff, NEXA, ELRO AB600, Domia Lite) to X10 equivalents,
- Some Oregon temperature sensors to RFXSensor format,
- ATI Remote Wonder 21 bits extended to 32 bits (zeroes added)

In Variable length mode these signals can be received:
- X10 lighting and X10 security,
- Digimax,
- ARC-Tech (KlikOn-KlikOff, NEXA, ELRO AB600, Domia Lite) converted to their X10 equivalents,
- RFXSensor devices (433.92MHz version)
- RFXPower & RFXMeter devices,
- ATI Remote Wonder,
- cent-a-meter Electrisave,
- Oregon Scientific sensors.
The first byte indicated the received RF packet length in bits.

Bert

[Snelvuur]

lfrancios: http://www.xpl-perl.org.uk/changeset/215

These are the modified files which refer to the rfxcom support under xpl. Perhaps this can help you a bit aswell.

[lfrancois]

Thanks for your informations.

Now I get signal and I am able to manage it a bit, I am going to focus to analyze informations providing from my RFXPower.

So In reading rfxcom_rec/frmMain.vb from rfxcom, I tried to translate this code in perl. And finally I get this functions to check if the sequence is a rfxpower sequence or not:

Code: Select all

sub checkRFXpower
{
  my @bytes  = @_;
  my $bytesPrint;
  my $bytesNumber = 0;
  my $parity;

  $bytesNumber = scalar @bytes;
  return 0 if ($bytesNumber < 6);
  $parity = ~((($bytes[0] & 0xF0) >> 4) + ($bytes[0] & 0x0F)
                + (($bytes[1] & 0xF0) >> 4) + ($bytes[1] & 0x0F)
                + (($bytes[2] & 0xF0) >> 4) + ($bytes[2] & 0x0F)
                + (($bytes[3] & 0xF0) >> 4) + ($bytes[3] & 0x0F)
                + (($bytes[4] & 0xF0) >> 4) + ($bytes[4] & 0x0F)
                + (($bytes[5] & 0xF0) >> 4)) & 0x0F;
  # $parity = $parity ^ 0x0F;
  print "parity checked ...\n";
  if ((($bytes[5] & 0x0F) == $parity)
      && ($bytes[0] + ($bytes[1] ^ 0x0F)) == 0xFF) {
        return 1;
  }
  return 0;
}

The problem to day is I never fill the condition I wrote. So far some sequences with more of 6 bytes:
bytes -> 0a4d10061022
bytes -> 32241055371b
bytes -> 1006102200001d
bytes -> 1a2d10d3222420
bytes -> 0a4d1006102200
bytes -> 1a2d10d32224

But no one match the rfxpower condition

Could you help to debug it?

Thanks a lot, Ludo

PS: You have the full code at this URL:
- http://www.zoxx.net/~ludo/rfxcom.txt

[b_weijenberg]

Ludo,

You have to put the receiver in Variable Length mode (command hex F02C)

The first byte you receive will contain the message length in bits. For an RFXPower this will be hex 30 (48 decimal)

1) Check the number of bits received - should be hex 30,
2) Check if the 2 address bytes have the correct format: Byte 2 = byte 1 with the complement of the upper nibble (bit 7-4)
3) Check the 4 bits parity: This is the complement of:
byte 0 bit 7-4 + byte 0 bit 3-0 + byte 1 bit 7-4 + byte 1 bit 3-0 + byte 2 bit 7-4 + byte 2 bit 3-0 + byte 3 bit 7-4 + byte 3 bit 3-0 + byte 4 bit 7-4 + byte 4 bit 3-0 + byte 5 bit 7-4

If this check is OK it is 99.999% sure it is an RFXPower or RFXMeter packet

bert

[beanz]

Ludo,

I think your perl code is reading parts of messages. What I do is do a read, check the length in the first byte and if I don't have enough data I do another read ... appending the new data to the end. When I have enough I remove those bytes and keep the rest in case they are part of the next message - though actually this may not be the best strategy for staying in sync. You don't seem to be doing this, you seem to be throwing the bits away if you don't have enough data.

-Mark.