Skip to main content

You are here

Who (what) is it......

79 posts / 0 new
Last post
jcw

Ooh, interesting - this is what I get (with the long lines truncated for this post):


>P 686 6 0 0 R2 A686 R4 94C0 R9 C4A3 scanpulses start t=125510 pulse n=15 b=125512 8100 e=125913 8000 scans=23364 14392 11084 35552 45184 836 275 pulse n=79 b=125935 8120 e=149043 8000 scans=38132 1236 5336 412 2880 408 4940 122 pulse n=5 b=149120 8100 e=149212 8000 scans=5366 820 26308 812 3296 812 pulse n=15 b=149230 8100 e=149386 8000 scans=9105 828 11504 1240 18484 816 5760 81 pulse n=237 b=149408 8120 e=160546 8000 scans=60415 1240 6160 408 4924 1244 6572 1 pulse n=1 b=160741 8100 e=160801 8000 scans=3526 824 pulse n=23 b=160816 8100 e=161067 8000 scans=14613 1224 51780 1224 6180 1220 15616 pulse n=7 b=161098 8140 e=161195 8000 scans=5629 816 4532 816 12324 832 16848 396 pulse n=21 b=161205 8100 e=161424 8000 scans=12741 432 5320 836 3272 412 5760 1228 pulse n=3 b=161471 8100 e=161551 8000 scans=4671 820 18500 816 pulse n=15 b=161565 8100 e=161729 8000 scans=9535 816 14788 836 824 820 9040 1224 pulse n=69 b=161754 8100 e=167093 8000 scans=49562 812 1240 812 4532 816 6568 420 pulse n=49 b=167158 8120 e=179372 8000 scans=57882 2052 11916 1236 4100 420 50956 pulse n=19 b=179418 8120 e=182354 8000 scans=40356 816 2472 812 1652 28344 5760 81 pulse n=47 b=182459 8100 e=182873 8000 scans=24103 1224 9044 816 20148 812 41912 8 pulse n=35 b=182910 8100 e=183365 8000 scans=26430 836 38208 812 21776 832 15188 8 pulse n=29 b=183394 8140 e=183711 8000 scans=18408 388 21364 1240 2468 816 13556 4 pulse n=1 b=183747 8120 e=192314 8000 scans=41682 812 pulse n=225 b=192332 8160 e=214138 8000 scans=27957 820 1236 812 1236 832 3688 820 pulse n=107 b=214316 8120 e=217256 8000 scans=40481 1228 3704 1220 3708 816 4528 8 pulse n=1 b=217341 8100 e=217402 8000 scans=3481 820 pulse n=195 b=217409 8120 e=222161 8000 scans=15355 816 3288 1240 2452 836 4924 81 pulse n=161 b=222315 8120 e=242130 8000 scans=43241 816 6176 816 2472 412 3684 832 pulse n=7 b=242280 8100 e=242365 8000 scans=4960 1240 5740 820 2060 408 13560 1236 pulse n=7 b=242393 8100 e=242523 8000 scans=7568 412 14792 816 21364 1240 30808 41 pulse n=189 b=242540 8100 e=248008 8060 scans=57123 27936 5748 832 2056 816 4528 1 pulse n=179 b=248609 8120 e=251299 8060 scans=25866 1240 8624 1236 2884 816 11500 pulse n=3 b=251530 8120 e=251631 8020 scans=5916 1220 39444 828 pulse n=1 b=251651 8120 e=251712 8020 scans=3545 820 pulse n=1 b=251728 8120 e=251789 8060 scans=3545 816 pulse n=7 b=251831 8120 e=251984 8020 scans=8910 412 34924 832 52168 424 3276 832 pulse n=13 b=252018 8120 e=252285 8020 scans=15586 816 52588 828 51368 28764 13144 pulse n=1 b=252310 8120 e=252370 8020 scans=3545 816 pulse n=5 b=252383 8120 e=252520 8020 scans=8000 836 18480 412 56716 816 pulse n=5 b=252551 8120 e=252657 8020 scans=6229 836 35740 816 8636 828 pulse n=1 b=252673 8120 e=252734 8020 scans=3545 820 pulse n=3 b=252750 8120 e=252824 8020 scans=4288 816 11908 832 pulse n=7 b=252836 8120 e=252984 8020 scans=8623 812 12740 828 43144 820 28760 828 pulse n=5 b=252999 8120 e=253155 8020 scans=9096 816 39864 812 25896 28356 pulse n=3 b=253181 8120 e=253285 8020 scans=6035 816 42320 412 pulse n=1 b=253310 8120 e=253371 8060 scans=3521 416 pulse n=1 b=253426 8120 e=253487 8020 scans=3545 816

Will look into this. I've never been able to pick up anything from the Energy Cost transmitter until now. Thanks.

Lemmingnl

This Swedish forum takes another approach by reading the EEPROM. On page three there is a file available for download that containts data from all the IC2 (to ROM) and SPI (to transciever) lines. Software to open the file is also linked. That data corresponds to what I recieve.

When looking for transmitter data, I scan for the following data: 0xYIIIIY, with Y don't care and I the ID of the transmitter. I then left-shift all incoming data by 4 places. I have identified the following data:

byte - data
0,1 - device id
2,3 - time on_tot (s)
4-7 - time on (s)
8-14 - Energy in Ws
15,16 - current power (in Wx10)
17,18 - max power (in Wx10)
19-21 - Energy in Ws
22-37 - unknown
36?-37 - # of resets, don't know how large this value can become
38-40 - hash, in 0x0HHHH0, with H the hash
41 - End of transmission? (seems to be constant)

bgonev

@NdyGen: I want to analyze your setup on my PC - so the question is: the wire soldered on the link between CPU and RF part - can i connect it to some TTL-RS232 converter ? The goal is to sneak the traffic on rs-232 port...

NdyGen

@bgonev, don't think RSR232 is fast enough to capture that and the protocol is not exactly a normal serial protocol.

Lemmingnl

Here are some datasets I recovered. They are longer than I think is needed but I might have overlooked some data.

jcw

How many sensors are you capturing?

Lemmingnl

Three, 5F70 (alarm clock), 5EAA (laptop) and DA67 (nothing).

-edit-

Do mind that the data shown is extracted from the recieved datastream. The data is not continuous!

thosch

The Energy Count 3000 packets start with a fixed pattern of 19 to 21 bytes. The common part (19 bytes) of it starts with 0xFC 0xCF 0x7E 0x5C, the bytes from RFM12B are received with most significant bit first.
The fixed pattern is often bit-shifted within the packet. I'm using RFM12B receive without SYNC-byte (FIFO command 0xCA8F), because receive with 1 SYNC-byte (0xFC or 0xCF etc. like above) did not work.

The attached RF12test9.pde has a new command 'E', which works like 'D', but bitshifts the received block if the start of the fixed pattern was found in it.

The EC3k packets received with 'D' or 'E' still do not contain meaningful data like Lemmingnl posted.
The Lemmingnl data contained lots of zero bytes. Therefore I assumed that the radio transmission must be somehow scrambled. Long sequences of same bits transmit bad on the radio channel, because the receiver clock would soon get out-of-sync.

Thanks to the Berlekamp-Massey algorithm I discovered a scrambler polynomial when I applied it to the start of the packets. The found polynomial is
x^20+x^19+x^18+x^17+x^15+x^14+x^13+x^12+x^3+x^2+x^1+1 or 0xF7807 in hexadecimal notation.
Descrambling the received packets with this polynomical converts the fixed pattern into a long sequence of 0x00 bytes. The 'E F' command of RF12test9.pde does this.

Then I reset one transmitter so that the data portion of its packets contains a lot of (scrambled) zero bytes. Applying the Berlekamp-Massey algorithm on the zeroed data portion found another scrambler polynomial: x^19+x^17+x^14+x^12+x^2+1 or 0x52802 hexadecimal.
The 'E 5' command of RF12test9.pde descrambles with this polynomial, but converts the leading fixed pattern into a long sequence of 0xFF bytes.

Even the descrambled data does not yet reveil data like Lemmingnl's post, not even my transmitter IDs. So I would appreciate your experiments with RF12test9.pde and hints how to further decode the EC3k transmissions.

AttachmentSize
RF12test9.pde46 KB
Flying

Has anyone got any further on this?

Lemmingnl

Not me. I have been busy with other stuff and have put this on a lower priority.

I have analysed the configuration of the reciever (I used transciever before but I am fairly sure that it is merely a reciever). Due to the large number of commands I assumed that the chip used is rather complex (ie not something like a RFM01). Complex chips all seem to use some form of adress byte followed by a databyte. This adress byte is assumed to contain a R/W bit. Further assuming that most (if not all) commands are write operations, I looked for a constant bit. The only bit that remains constant (except for the last command) is the first one. The next 7 bits all alter and seem to be adress bits. The reciever sends 0x04 during every first byte. During the second byte it seems to send the previous value stored in that register. This brings me to the curious observation that some registers are written to multiple times. If my assuption about a R/W bit and 7 adress bits is correct, the registers written to range from 0x02 to 7D. I have not found a datasheet that matches these observations.

thosch

HEUREKA!

The Energy Count 3000 packets are encoded with NRZS and scrambled with the polynomial x^17+x^12+1.
The descrambled data is "bit-stuffed" (like HDLC): a 0-bit is inserted after 5 consecutive 1-bits.
The un-"bit-stuffed" data is encoded LSBit first and shifted by 4 bits.

Energy Count 3000 packet decoding goes like this:

  1. Find the bit-offset of the common fixed pattern 0x13 0xF1 0x85 0xD3 0xAC 0xD2 in the packet. After this pattern the packets differ depending on the EC3k transmitter ID.
    The above pattern is the end of the common 18..21 bytes. The pattern I mentioned previously was the begin and right-shifted by 2 bits.
  2. Left-shift the packet by bit-offset mod 8 bits, i.e. shift lower to higher order bits.
  3. Descramble the left-shifted packet with a multiplicative self-synchronizing descrambler and the polynomial x^18+x^17+x^13+x^12+x+1 (0x31801 in hexadecimal notation). Then invert the bits of all bytes in the descrambled packet, i.e. xor them with 0xFF.
    This is equivalent to descramble with NRZS and then with x^17+x^12+1 (0x10800).
    Descrambling must start at least 3 bytes before the ID data after the fixed pattern, otherwise the scrambler would not be synchronized.
  4. Delete all 0-bits after 5 consecutive 1-bits starting at the descrambled ID data.
  5. Reverse the bit-sequence of all bytes starting at the ID data, i.e. move bit-7,6..0 to bit-0,1..7.
  6. Left-shift the packet with the reversed bits by 4 bits.
  7. Et voila: The Energy Count 3000 data appears like Lemmingnl logged it. (Thanks again!)

An implementation of the EC3k packet decoding will follow.

dabass
Sniff of the SPI traffic reveals that the radio chip is an Axsem AX5042. Protocol: FSK @ 868.3 MHz, deviation 150 KHz. Reset sequence: 0x02,0xE9 0x02,0xE9 0x02,0x60 Setup sequence: 0x03,0x02 (xtal) 0x11,0x07 (NRZI,ENC INV,ENC DIFF, ENC SCRAM) 0x2C,0x1D (868 band) 0x20,0x36 0x21,0x44 0x22,0x1C 0x23,0xCD -> 868.3 MHz 0x06,0x01 0x14,0xFF 0x15,0xFF 0x16,0xFF 0x17,0xFF -> CRC Init 0xFFFFFFFF 0x2B,0x20 0x29,0x00 0x3F,0x19 0x40,0x15 0x41,0x55 -> datarate 0x42,0x04 0x43,0x00 0x10,0x45 -> FSK 0x08,0x00 0x3B,0x0E 0x3C,0x00 0x38,0x01 0x39,0x0E 0x3A,0x11 0x44,0x03 0x45,0x08 0x46,0x0A 0x72,0x01 0x73,0x01 0x7D,0x35 0x47,0x06 0x78,0x00 0x79,0x10 0x7A,0x35 0x12,0x04 0x7C,0x23 0x0C,0xF7 0x2A,0x03 0x02,0x68 0x02,0x68 0x74,0x00 Start receive: 0x2D,0x18 0x02,0x09 Long time scan on a simple spectrum analyser gives the following result:

http://emwires.com/bitcoinshop/hardware_images/voltcraft8683.jpg

Lemmingnl

Amazing! Pretty nifty stuff for a low-cost metering set. That chip is (in my opinion) overkill for such an application.

dabass

I don't think it's overkill, I just think that the Axsem chips are amazingly cheap compared to other manufacturers.

If you take into account that the version used here is the 'blob' version and a production run of at least 100.000, I would not be surprised if it is a lot less than US$0.50.

thosch: how do you actually recognize packets from this thing? I have scanned for variations of 0xFC 0xCF 0x7E 0x5C .. 0x13 0xF1 0x85 0xD3 0xAC 0xD2 at 868.3 MHz as you suggest, but I cannot find any packets as you have.

Do you have any raw data dumps of the packet bits / bytes received (without any processing / bitshifting etc.) ?

thosch

Attached a log from RF12test9.pde (rf12test.30.cap minicom capture) and Energy Count 3000 packet decoding on that (rf12test.30.ec3k).

You'll find the used RFM12B register settings before the "drecvintr start" line in rf12test.30.cap, e.g. "R2 A686" for the frequency 868.350 MHz. The register numbers Rn plus 1 are the "Control register" numbers in the RFM12B manual (or the Si4421 manual from Silicon Labs).

Which RFM12B register settings do you use? The 'R' command of RF12test9.pde shows them all.

I recognize the packets by looking for the pattern 0x13 0xF1 0x85 0xD3 (unshifted) starting at offset 13 in the received packets. I also look for bit-shifted variations of 0x13, 0xF1, 0x85, 0xD3, 0xAC, i.e.
0x27 0xE3 0x0B 0xA7 left-shifted 1 bit
0x4F 0xC6 0x17 0x4E left-shifted 2 bits
0x9F 0x8C 0x2E 0x9D left-shifted 3 bits
0x3F 0x18 0x5D 0x3A left-shifted 4 bits
0x7E 0x30 0xBA 0x75 left-shifted 5 bits
0xFC 0x61 0x74 0xEB left-shifted 6 bits
0xF8 0xC2 0xE9 0xD6 left-shifted 7 bits
When one of these patterns is matched I left-shift the whole packet 8 - n bits, e.g. 6 bits if the 2-bit-left-shifted pattern is found.
5 (not 4) bytes must be used for creating the bit-shifted patterns, so that their 4th byte's lower bits get the MSBits from the 5th byte shifted in. Otherwise the lower bits of the 4th byte would be zero and the bit-shifted patterns would not match the received packet.

Another method would be to descramble the packet and then look bit-wise for the pattern 0x55 0x55 0x55 0x7E, where the 0x7E is the HDLC-FLAG before the EC3k data.
Descramble with the descramb() function in RF12test9.pde using scrampoly = 0x31801 plus bit-inversion, i.e. xor every descrambled byte with 0xFF.

dabass: Can you provide the Axsem AX5042 programming manual?

AttachmentSize
RF12test9.log30.zip32.6 KB
jcw

Fantastic results - I've extracted the successful decodes from the ec3k file (see attached). Was wondering about the different ID's, why are there so many of them? Especially the first unique values: is that because decoding is not 100% exact yet?

AttachmentSize
decoded ec3k's.png131.58 KB
thosch

I'm pretty sure, that the decoding is correct. But there apparently are occasional receive errors. The IDs of my EC3k transmitters are D892 D3AA 6F05 6EA1 (see header comment in rf12test.30.ec3k), all others are erroneous receptions.

There seems to be a hash/checksum at the end of the EC3k packets (see Lemmingnl 's post 2011-11-22), but I do not yet know its algorithm and therefore I cannot surely exclude erroneous receptions.
Instead I do some heuristic checks (the "EC3K ... ERR" lines in rf12test.30.ec3k) to exclude erroneously received packets.

There are other transmission errors, e.g. total time (sT) ON-time (sON) and watt-seconds (Ws) should be monotonically increasing (except for an EC3k transmitter reset), but some decoded packets violate this.

Meanwhile I tuned some RFM12B parameters:
R4 94A2 LNA gain 0dBm instead of -6dBm (was R4 94AA)
R9 C4A7 AFC high accuracy enabled instead of disabled (was R9 C4A3)
I also changed the place of the JeeLink with the RFM12B receiver and its antenna is now horizontal at right angle to the JeeLink housing instead of vertical. This reduced the rate of bad packets from 65% (rf12test.30.ec3k) to ca. 20%.

jcw

I'd like to try and replicate the EC3K decoding you did (got a few of those here too). I tried "E 0", "E 5", and "E F", but I don't seem to get any useful data so far (first 65 data bytes are always 0 as far as I can tell).

Register settings are:

R0 80E7 R1 820D R2 A686 R3 C610 R4 94AA R5 C2AC R6 CA8F R7 CEAA R9 C4A7 RA 9820 RB CC77 RD E000 RE C800 RF C049

Update - ignore comment about 0's, that was probably a bad RFM12B - different unit gives data. Attached a random example.

thosch

My state of work on the EC3k decoder might be helpful. Please try the 'EC' and 'E D' commands of the attached RF12test13.pde. (I'd better not hide too long in the "Cathedral" and go to the "Bazaar" instead ... ;-)

If you are using a JeeNode you might want to disable the "DATAFLASH" code in RF12test13.pde.

The packet length "len=69" (and =70) and time "+27292" (microseconds) in your screen shot are the same as on my side.
Good receptions should have many "stat" bytes with the CRL bit on (0x40 Clock recovery locked).

AttachmentSize
RF12test13.pde93.32 KB
jcw

Ok, with E C, I'm receiving something - but it looks like the decodes were accidental hits:


>e c R2 A686 R3 C610 R4 94A2 R5 C2AC R6 CA8F R7 CEAA R9 C4A7 drecvintr start t=199825 recv len=69 ovr=0 r=200637512 01C0 b=200637672 +160 8100 81C0 e=200665228 +27556 8080 stat=8080 crl=45 boffs 168 recv len=70 ovr=0 r=210693756 0120 b=210694060 +304 8120 81E0 e=210722008 +27948 80C0 stat=80C0 crl=43 boffs 166 recv len=69 ovr=0 r=215986904 0120 b=215986968 +64 8120 8140 e=216014616 +27648 8000 stat=8000 crl=46 boffs 169 EC3K 225740576 ID=59AD 64942080 sT 19657624 sON 36176 Wh 0.0 W 432.2 Wmax 1 resets (12 noCRL) recv len=68 ovr=0 r=245807564 0160 b=245807856 +292 8160 8160 e=245835116 +27260 8000 stat=8000 crl=47 boffs 163 recv len=70 ovr=0 r=251075136 0140 b=251075216 +80 8140 8160 e=251103252 +28036 8000 stat=8000 crl=47 boffs 172 recv len=70 ovr=0 r=256086140 0100 b=256086224 +84 8180 8140 e=256114272 +28048 8000 stat=8000 crl=47 boffs 170 recv len=70 ovr=0 r=260748200 8100 b=260748184 -16 8100 81C0 e=260776240 +28056 8020 stat=8020 crl=49 boffs 174 recv len=69 ovr=0 r=265864940 0120 b=265865212 +272 8120 8160 e=265892900 +27688 8020 stat=8020 crl=49 boffs 168 recv len=70 ovr=0 r=267656872 0120 b=267657228 +356 8120 8120 e=267684860 +27632 8020 stat=8020 crl=0 boffs 171 recv len=70 ovr=0 r=275896188 0140 b=275896408 +220 8140 8140 e=275924456 +28048 8080 stat=8080 crl=44 boffs 167 recv len=70 ovr=0 r=280835928 01A0 b=280836172 +244 8160 8160 e=280864196 +28024 8080 stat=8080 crl=50 boffs 170 recv len=69 ovr=0 r=286179608 01A0 b=286179852 +244 8180 8160 e=286207400 +27548 8000 stat=8000 crl=42 boffs 166 recv len=69 ovr=0 r=300872932 0160 b=300873232 +300 8160 81C0 e=300900880 +27648 8020 stat=8020 crl=52 boffs 164 recv len=70 ovr=0 r=0 0020 b=302795636 +0 8120 8160 e=302823296 +27660 8020 stat=8020 crl=8 boffs 174 recv len=71 ovr=0 r=307659604 0120 b=307659824 +220 8120 8120 e=307687944 +28120 8020 stat=8020 crl=17 boffs 174 recv len=70 ovr=0 r=321036284 01A0 b=321036620 +336 81A0 81DE e=321064516 +27896 8020 stat=8020 crl=41 boffs 166 recv len=69 ovr=0 r=325976316 01E0 b=325976580 +264 8160 81E0 e=326004236 +27656 8020 stat=8020 crl=52 boffs 164 recv len=70 ovr=0 r=336007100 0140 b=336007372 +272 8140 8140 e=336035448 +28076 8020 stat=8020 crl=52 boffs 171 recv len=70 ovr=0 r=0 00A0 b=341077828 +0 81A0 81E0 e=341105888 +28060 8000 stat=8000 crl=48 boffs 175 recv len=70 ovr=0 r=346118540 0120 b=346118736 +196 8120 8160 e=346146776 +28040 80E0 stat=80E0 crl=38 boffs 173 recv len=70 ovr=0 r=351079108 01A0 b=351079148 +40 81A0 81FF e=351107152 +28004 80E0 stat=80E0 crl=49 boffs 174 recv len=69 ovr=0 r=356372384 0160 b=356372436 +52 815F 8140 e=356400000 +27564 80E0 stat=80E0 crl=42 boffs 169 recv len=70 ovr=0 r=361160736 0100 b=361160768 +32 8100 8140 e=361188812 +28044 8020 stat=8020 crl=63 boffs 173 recv len=70 ovr=0 r=366407828 01A0 b=366407960 +132 81A0 81DE e=366436000 +28040 8080 stat=8080 crl=40 boffs 174 recv len=70 ovr=0 r=371469396 0140 b=371469636 +240 8100 8140 e=371497636 +28000 8000 stat=8000 crl=45 boffs 168 recv len=70 ovr=0 r=376485008 0100 b=376485220 +212 8140 8140 e=376513220 +28000 8000 stat=8000 crl=42 boffs 168 EC3K 381450320 ID=59AD 64942080 sT 19657624 sON 36176 Wh 0.0 W 432.2 Wmax 1 resets (7 noCRL) recv len=71 ovr=0 r=382888168 0180 b=382888300 +132 8100 8100 e=382916272 +27972 8000 stat=8000 crl=7 boffs 174 recv len=69 ovr=0 r=386137636 0140 b=386137732 +96 8140 8140 e=386165396 +27664 8040 stat=8040 crl=48 boffs 168 recv len=70 ovr=0 r=396244620 0120 b=396244840 +220 8120 8160 e=396272888 +28048 8060 stat=8060 crl=45 boffs 168 recv len=71 ovr=0 r=401235048 01E0 b=401235120 +72 81E0 81DE e=401263356 +28236 8000 stat=8000 crl=48 boffs 170 recv len=70 ovr=0 r=406305484 0140 b=406305704 +220 8140 81DE e=406333620 +27916 8000 stat=8000 crl=48 boffs 173 recv len=69 ovr=0 r=411240928 0300 b=411241320 +392 81C0 81C0 e=411268924 +27604 8000 stat=8000 crl=43 boffs 165 recv len=70 ovr=0 r=413137364 0300 b=413137752 +388 8100 8100 e=413165484 +27732 8000 stat=8000 crl=3 boffs 170 recv len=69 ovr=0 r=446405244 0180 b=446405400 +156 8100 8140 e=446433068 +27668 8080 stat=8080 crl=42 boffs 168 recv len=68 ovr=0 r=451416156 0120 b=451416528 +372 8160 81A0 e=451443744 +27216 8060 stat=8060 crl=46 boffs 164 recv len=70 ovr=0 r=476493992 0160 b=476494040 +48 8160 8160 e=476522112 +28072 8080 stat=8080 crl=41 boffs 171 recv len=48 ovr=0 r=481786908 0160 b=481786968 +60 8160 8120 e=481806224 +19256 8020 stat=8020 crl=25 boffs 173 recv len=49 ovr=0 r=491565788 0120 b=491565828 +40 8120 8160 e=491585480 +19652 8020 stat=8020 crl=26 boffs 173 recv len=69 ovr=0 r=518337484 01C0 b=518337816 +332 81C0 81DD e=518365440 +27624 8000 stat=8000 crl=62 boffs 172 recv len=48 ovr=0 r=566799228 0120 b=566799388 +160 8120 8160 e=566818580 +19192 8020 stat=8020 crl=27 boffs 172 recv len=70 ovr=0 r=576779984 01A0 b=576780360 +376 819F 81DE e=576808268 +27908 8020 stat=8020 crl=41 boffs 168 recv len=70 ovr=0 r=581795480 01E0 b=581795736 +256 8160 8160 e=581823772 +28036 8000 stat=8000 crl=44 boffs 171 recv len=69 ovr=0 r=586811180 0100 b=586811536 +356 8100 8140 e=586839192 +27656 8020 stat=8020 crl=51 boffs 167 recv len=69 ovr=0 r=591826972 0160 b=591827220 +248 81E0 81E0 e=591854820 +27600 8000 stat=8000 crl=49 boffs 165 recv len=70 ovr=0 r=596842304 01C0 b=596842408 +104 8180 81DF e=596870476 +28068 8000 stat=8000 crl=50 boffs 173 recv len=70 ovr=0 r=601857920 0140 b=601858008 +88 8140 8100 e=601886036 +28028 8020 stat=8020 crl=39 boffs 173 recv len=70 ovr=0 r=603677724 0320 b=603678088 +364 8120 81A0 e=603705764 +27676 8020 stat=8020 crl=2 boffs 167 recv len=70 ovr=0 r=606873596 0120 b=606873804 +208 8120 8160 e=606901876 +28072 8000 stat=8000 crl=39 boffs 169 recv len=47 ovr=0 r=611939848 0100 b=611940080 +232 8140 81C0 e=611958880 +18800 8000 stat=8000 crl=31 boffs 164 recv len=68 ovr=0 r=616955324 0100 b=616955616 +292 8100 81C0 e=616982896 +27280 8020 stat=8020 crl=50 boffs 165 recv len=70 ovr=0 r=627263752 01A0 b=627263948 +196 8120 8160 e=627292020 +28072 8000 stat=8000 crl=44 boffs 172 recv len=70 ovr=0 r=632254276 01C0 b=632254356 +80 81C0 81FF e=632282352 +27996 8000 stat=8000 crl=50 boffs 172 recv len=69 ovr=0 r=636967248 03E0 b=636967628 +380 8160 81E0 e=636995272 +27644 8000 stat=8000 crl=50 boffs 164 recv len=69 ovr=0 r=652064288 0120 b=652064616 +328 8160 8160 e=652092232 +27616 8020 stat=8020 crl=48 boffs 169 recv len=71 ovr=0 r=653782796 01A0 b=653782992 +196 81A0 8120 e=653810944 +27952 80A0 stat=80A0 crl=0 boffs 175 recv len=70 ovr=0 r=657079916 0120 b=657080164 +248 8120 8120 e=657108156 +27992 80A0 stat=80A0 crl=37 boffs 170 recv len=69 ovr=0 r=667363492 0300 b=667363884 +392 81C0 8180 e=667391512 +27628 8020 stat=8020 crl=46 boffs 165 recv len=70 ovr=0 r=672126728 01E0 b=672126940 +212 81E0 81FD e=672154980 +28040 8080 stat=8080 crl=57 boffs 171 recv len=69 ovr=0 r=682132752 01A0 b=682133080 +328 8100 8120 e=682160732 +27652 80A0 stat=80A0 crl=51 boffs 168 recv len=69 ovr=0 r=692416508 01C0 b=692416492 -16 81C0 8160 e=692444028 +27536 8020 stat=8020 crl=48 boffs 170 recv len=70 ovr=0 r=697431808 0120 b=697432052 +244 8120 8160 e=697460104 +28052 8000 stat=8000 crl=46 boffs 171 recv len=69 ovr=0 r=702225404 0180 b=702225632 +228 81FE 81FE e=702253244 +27612 8000 stat=8000 crl=50 boffs 164

Would it be of any help to collect a long stretch of E D data? I've got two units transmitting here, one a few meters away (using std JeeNode btw, no DataFlash).

jcw

You say the decoding is NRZ -> descramble -> bit unstuffing. Wouldn't it be more logical to do it as NRZ -> bit unstuffing -> de-scramble? Doing it in the wrong order would still work as long as there are no runs of 5 1's in the data.

I think that it would make sense for the NRZ encoder to insert a 0 after every 5 1's regardless of packet scrambling, since bit-stuffing is part of the lowest level mechanism to avoid long unbalanced stretches of 0's or 1's, whereas the polynomial is presumably a higher-level protocol detail.

thosch

May be the center frequency of your EC3k transmitters is different from mine.
Try to vary it with e.g. 'R2 A680' (868.3200 MHz) or 'R2 A690' (868.4000 MHz).
Or open the AFC wider with 'R9 C497' (+15..-16) or even 'R9 C487' (no restriction). You will see the AFC frequency changes in the low order bits of the "stat" line bytes.

I remember that your results with the 'P 686 6 0 0' command on 2011-11-21 differed from mine.
With 'P 686 6 3 2' I get

R2 A686
R4 94DA
R9 C4A7
scanpulses start t=31588526
pulse n=1 b=31588534 81BF e=31588622 8000 scans=4864 27448
pulse n=1 b=31589005 8180 e=31589092 8020 scans=4864 27448
pulse n=1 b=31589274 81E0 e=31589362 8000 scans=4887 27856
pulse n=1 b=31593609 8180 e=31593697 8000 scans=4863 27428
pulse n=1 b=31593979 8180 e=31594066 8000 scans=4887 27852
pulse n=1 b=31594199 8140 e=31594286 8000 scans=4887 27856
scanpulses exit t=31596252 np=6

These are just the EC3k packets each ca. 27 milliseconds long, the last numbers on each line are the pulse lengths in microseconds.

After any 'P' command make sure to do 'R4 94A2' to set the Receiver Control register back to its good default, the 'P' command modifies it according to its parameters bw (bandwidth), lna (LNA gain), rssi (RSSI threshold).
Otherwise the next 'E D' or 'EC' command would not work.

jcw

Thx, the R9 C487 cmd seems to capture a bit more.

If I look at packets with lengths 68..71 bytes, and keep only the ones matching 13 F1 85, then I do get some patterns. Attached a view of 16 such packets, showing 3 arbitrary bytes, then that pattern, then the rest. The bit decoding doesn't appear to be robust yet, I see several places where things start to shift by 1 or more bits. Also, this misses about half the packets which do not match precisely on 13 F1 85, so there are still a fair number of bit errors in there.

jcw

I get this:

>P 686 6 3 2 R2 A686 R4 94DA R9 C487 scanpulses start t=7141369 pulse n=1 b=7143950 8120 e=7144038 8020 scans=5104 27536 pulse n=1 b=7148941 81E0 e=7149028 8060 scans=5104 27532 pulse n=1 b=7154057 81A0 e=7154145 8020 scans=5103 27520 pulse n=1 b=7158996 81A0 e=7159085 8020 scans=5103 27528 pulse n=1 b=7163987 8120 e=7164075 8060 scans=5104 27540 pulse n=1 b=7169103 81E0 e=7169191 8060 scans=5128 27944 pulse n=1 b=7174018 8160 e=7174106 8020 scans=5104 27536 pulse n=1 b=7179134 8160 e=7179223 8020 scans=5103 27520 pulse n=1 b=7183998 8120 e=7184087 8020 scans=5104 27540 pulse n=1 b=7188988 8120 e=7189076 8020 scans=5104 27536 pulse n=1 b=7194131 8120 e=7194218 8020 scans=5103 27520 scanpulses exit t=7196839 np=11

I have no idea what it all means. Have been using your test code without really understanding what I'm doing... :)

But there's definitely something valid going on here. If I extract the few successful decodes, there's a clear set of values emerging:

EC3K 2751894652 ID=59AD 64942080 sT 19658998 sON 36206 Wh 77.1 W 432.2 Wmax 1 resets (4 noCRL) EC3K 2832143712 ID=59AD 64942080 sT 19659078 sON 36208 Wh 76.8 W 432.2 Wmax 1 resets (15 noCRL) EC3K 3058198184 ID=59AD 64942080 sT 19659303 sON 36213 Wh 76.6 W 432.2 Wmax 1 resets (12 noCRL) EC3K 3123401508 ID=59AD 64942080 sT 19659368 sON 36214 Wh 76.3 W 432.2 Wmax 1 resets (17 noCRL) EC3K 3133079292 ID=59AD 64942080 sT 19659378 sON 36214 Wh 76.4 W 432.2 Wmax 1 resets (11 noCRL)

Those last two were reported within 10s of each other, the Wh value is steadily increasing, the ID is consistent, and the Watts reported make sense, sort of.

thosch

Bit-unstuffing before descramble or NRZS does not work: there ARE sequences of 5 1-bits plus a 0-bit in the raw (scrambled) data. Bit-unstuffing these 0-bits would influence the descrambler so that different (wrong) data would come out.

The purpose of the bit-stuffing is to prevent HLDLC flags 0x7E from appearing within HDLC frames. It does not prevent unbalanced stretches of 0-bits and even 80% 1-bits, 20% 0-bits is quite unbalanced. (Long ago I had to learn that HDLC framing alone does not make good radio transmission and scrambling the data payload of the HDLC frames was needed.)

I'm pretty sure that EC3k transmits HDLC frames: There are HDLC flags 0x7E before and after the EC3k packet in the descrambled data. The EC3k packet checksum is CRC-CCITT, which is compliant with the HDLC standard. The EC3k packet bytes are transmitted LSBit first, also compliant with the HDLC standard.

The sequence of NRZS decoding and descrambling does not matter. NRZS is equivalent to NRZI plus bit-inversion.
IMHO scrambling and NRZ is overkill: scrambling alone (even only with x^17+x^12+1) already "whitens" the data enough, i.e. makes it look like pseudo-random noise.
RF12test13.pde does not separate NRZS and descrambling, but its descramb() function does both in one run with the combined polynomial.

It's also strange that the 18..22 bytes 0x55 (preamble), which appear in the descrambled data before the EC3k HDLC frame, are scrambled. IMHO the receiver could easier tune its radio with serveral plain (unscrambled) 0x55 bytes preceding the transmission.

thosch

Some explanations of the RF12test13.pde output:

scanpulses start t=7141369
start was at 7141369 millis() since the JeeNode/JeeLink was reset.

pulse n=1 b=7143950 8120 e=7144038 8020 scans=5104 27536
DRSSI rised at b=7143950 millis(), the RFM12 status was 0x8120 at that time.
At e=7144038 millis() DRSSI was off for 60 milliseconds, the final RFM12 status was 0x8020.
n=1 DRSSI pulse was found between the b= and e= times, this pulse was 27536 micros() long.
The scan loop ran scans=5104 times which lasted e - b = 88 milliseconds in total, i.e. the pulse scanning resolution was ca. 17 microseconds = 88000 / 5104.

scanpulses exit t=7196839 np=11
scanpulses() terminated at 7196839 millis(), total np=11 pulses (or pulse sequences) were found.

EC3K 3133079292 ID=59AD 64942080 sT 19659378 sON 36214 Wh 76.4 W 432.2 Wmax 1 resets (11 noCRL)
Receive of this raw packet started at 3133079292 micros().
"sT" means seconds Total time, "sON" means seconds ON-time decoded from the EC3k packet.
The EC3k transmitter had 1 reset (pressing its red light until steady, then release it).
"(11 noCRL)": Within the 41 bytes EC3k data 11 bytes were received with status CRL bit off.

See the comment above ec3kdecode() in RF12test13.pde for the layout of the EC3k packets.

It's strange that the "sT" from your EC3k does not increase, but only the "sON".

mvdswaluw

Just a quick question. Just a yes no will do. I don't want to pollute this wonderfull topic. Can a sensor be monitored without pairing with the receiver first? I'm thinking about buying a few sensors to do the same you do here, but wonder if I need the receiver/display...

Lemmingnl

Yes, the sensors transmit every 5 seconds, I have not found the need to pair them first.

dabass

Hey thosch,

Thanks for the log, I will have a look at it and try to see how it matches up to my data.

I am not using the RFM12B (or Si4421), I am using something Si4432 based, so I don't think the register settings will make a lot of sense to you.

I downloaded the AXSEM programming manual about 10 months ago from the AXSEM site when I was evaluating a project, but I now see that they have hidden it behind a username / password for some reason and a quick scan of the Google for AX5042_PM_V2_4.pdf shows no hits anymore. I think they really don't want you to have it :-) You can always register to see if they will let you in.....

@jcw: Is there a PM system or something on this message board ?

martynj

Dabass, click on the username to view their profile - a PM tab will appear if they have chosen to enable.

Pages

Premium Drupal Themes by Adaptivethemes