Structure of Tytera MD-380 .test radio calibration settings file.

Continuing from my previous post, Reading and Backing up Tytera MD-380 calibration settings, here are some notes on the structure of the saved .test file.  I'm trying to decode the layout using hexdump -C.

First here are the screen shot of the data for reference:


Now here is the hexdump -C output.

00000000  0a 96 89 ad 4b 82 7b ff  62 68 6e ff ff ff ff ff  |....K.{.bhn.....|
00000010  91 92 93 90 8d 8d 8d 8f  91 ff ff ff ff ff ff ff  |................|
00000020  4d 4d 4d 4b 49 45 41 41  42 ff ff ff ff ff ff ff  |MMMKIEAAB.......|
00000030  5e 74 8b 9c ae bf d0 dd  ea ff ff ff ff ff ff ff  |^t..............|
00000040  1c 1a 19 19 19 19 19 19  1a ff ff ff ff ff ff ff  |................|
00000050  2d 2a 28 27 27 2c 31 2d  2a ff ff ff ff ff ff ff  |-*('',1-*.......|
00000060  35 32 2f 2c 2a 2b 2c 2c  2c ff ff ff ff ff ff ff  |52/,*+,,,.......|
00000070  36 34 33 2f 2c 31 36 33  31 ff ff ff ff ff ff ff  |643/,1631.......|
00000080  03 03 04 04 04 04 04 04  04 ff ff ff ff ff ff ff  |................|
00000090  25 24 23 22 22 21 20 1f  1f ff ff ff ff ff ff ff  |%$#""! .........|
000000a0  2b 2a 2a 28 27 26 26 25  24 ff ff ff ff ff ff ff  |+**('&&%$.......|
000000b0  37 36 36 35 35 34 33 31  2f ff ff ff ff ff ff ff  |76655431/.......|
000000c0  64 64 64 64 64 64 64 64  64 ff ff ff ff ff ff ff  |ddddddddd.......|
000000d0  1f 1d 1c 1c 1d 1c 1c 1c  1c ff ff ff ff ff ff ff  |................|
000000e0  80 80 80 80 80 80 80 80  80 ff ff ff ff ff ff ff  |................|
000000f0  1e 1e 1e 1e 1e 1e 1e 1e  1e ff ff ff ff ff ff ff  |................|
00000100  00 00 00 00 00 00 00 00  00 ff ff ff ff ff ff ff  |................|
*
00000130  33 2f 2c 29 27 25 23 20  1d ff ff ff ff ff ff ff  |3/,)'%# ........|
00000140  5f 5c 5a 58 56 54 52 51  50 ff ff ff ff ff ff ff  |_\ZXVTRQP.......|
00000150  00 00 00 00 00 00 00 00  00 ff ff ff ff ff ff ff  |................|
*
00000170  32 32 32 32 32 28 1e 1e  1e ff ff ff ff ff ff ff  |22222(..........|
00000180  7f 7d 7b 79 77 70 6a 6b  6d ff ff ff ff ff ff ff  |.}{ywpjkm.......|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 35 10 40 00 45 10 40  00 35 10 41 00 45 10 41  |.5.@.E.@.5.A.E.A|
000001c0  00 35 10 42 00 45 10 42  00 35 10 43 00 45 10 43  |.5.B.E.B.5.C.E.C|
000001d0  00 35 10 44 00 45 10 44  00 35 10 45 00 45 10 45  |.5.D.E.D.5.E.E.E|
000001e0  00 35 10 46 00 45 10 46  00 35 10 47 00 45 10 47  |.5.F.E.F.5.G.E.G|
000001f0  00 95 99 47 00 50 99 47  00 00 00 00 00 00 00 00  |...G.P.G........|
00000200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00002000

So MD-380.exe, writes out 8 KB, but it looks like only 512 bytes are actually used. the bytes from 512-8192 are all set to 0xFF.

First thing that is easy to spot by eye, the row labeled "Mod1 Partial is all 128 (decimal) which is 0x80 in hex.  A row of '80 80 80' appears at the line with the address 0xE0 (224 bytes into the file). 

There are 9 columns in the GUI and it is easy to see that most of the rows of 16 bytes have 9 values and 7 bytes of 0xFF.  So that's a nice convenient 16 byte per row layout in the file.

Moving up in the screen shot, the first row with data in all columns is "Tx Hight Power" with values of 145, 146, 147, 144 which is hex 91, 92, 93, 90.  This is easy to spot in the second row of the hexdump. 

So there are only 16 bytes before that.  The GUI shows 13 rows before that, but the 11 rows VOX1, VOX10, ..., Freq. Adjust (Low), only have values in one column.  So next step is to locate these values, which are 10, 150, 137, 173, (hex 0a, 96, 89, ad).  Those as easily spotted as the first bytes of the file starting at offset 0.  There are 11 bytes there that aren't 0xFF.

OK so far we know:

• Rows 2-13 (VOX 1, ... Freq. Adjust Low) are stored in the first 11 bytes 0x00 - 0x0a.
• Rows 14-39(?) are stored from bytes 0x10 - 0x18F, as 16 bytes per row using only the first 9 bytes for each calibration value.

That leaves the frequencies that are listed in the first two rows 'Rx Freq' and 'Tx Freq'.  It looks like these are encoded as 4 bytes in the 72 bytes located at 0x1b0 - 0x1f7.

It should be pretty easy to map this into Chirp's bitwise definition.

Hopefully this will be of use to some.
--Rob

Hacking the Z-Wave Protocol with a Hack-RF

More cool stuff for home automation and hacking:

I've been doing a lot with using rtl_433 and an rtl-sdr to receive temperature and humidity sensors, outdoor weather stations, and security system sensors (aka contacts).

So, I've been wondering about receiving and decoding home automation RF protocols like Z-Wave, Insteon, Zigbee which aren't terribly open.  The other day I saw this article on the RTL-SDR.com blog, "Hacking the Z-Wave Protocol with a Hack-RF", about a Shmoocon talk.  Exactly what I've been waiting for.  I have a HackRF in that I haven't been doing much with ... yet.

I assumed it would be possible to receive Z-Wave with an RTL-SDR.   There are a number of USB Z-Wave sticks that are starting to get popular.  Many home automation controllers that have one of the protocols implemented are fairly expensive and somewhat closed.

So I'm excited to see this, quoting the RTL-SDR.com post

Z-wave is a wireless protocol that is used often in applications like smart home and industrial automation. It essentially allows various wireless nodes to connect and talk to one another within your house, using 900 MHz wireless technology. Some common examples of Z-wave node products might be wireless controlled lights, door locks, thermostats and other security devices like motion detectors.

Recently at Shmoocon 2016 (a yearly hacking and security themed conference), presenters Joseph Hall and Ben Ramsey showed how they were able to use a HackRF software defined radio and some GNU Radio based software to not only sniff Z-wave packets, but to also control Z-wave devices. What’s also interesting is that they found that encryption on z-wave devices was rarely enabled, except for five out of nine door locks that they tested where it was enabled by default.

See the full story at Hackaday and have a look at their code on GitHub.

Unfortunately it looks like their stuff requires two HackRFs, one for transmitting and one for receiving. I unfortunately, only have one HackRF. There has been some work to enable better T/R (Transmit/Receive) switching into the HackRF libraries. I've seen the commits go by but haven't looked into them much yet.

Things are getting interesting, stay tuned for more...

Links:

• RTL-SDR.com - "Hacking the Z-Wave Protocol with a Hack-RF"
• Hack-a-day Story 
• GitHub Repo.

Acurite 592TXR Temperature and Humidity Sensors now decoded by rtl_433.

I've added decoding of Acurite's 592TXR "Tower" temperature and humidity sensors to rtl_433. These are small, inexpensive, wirelesss (433 Mhz), temperature and humidity sensors. The 592TXR has several different model numbers including 06002RM

These are compatible with Acurite's consoles such as the 01512 that I have as well as Acurite's Acu-Link Internet bridge which posts to acu-link's web page as well as weatherunderground. I picked up the Acurite 5-n-1 Weather Station, a console, and the internet bridge because the support for the 5-n-1 had been added to rtl_433 and the package price was pretty reasonable.

There were a number of people interested in decoding the 592TXR, but for some reason, it never got added, so I finally added it and cleaned up the Acurite 5-n-1 weather station decoding. The pull request got merged November 8th, 2015.

I think the temperature only version, the 592TX, should also be supported but I don't have one to test. Please let me know if it decodes successfully or not.

The protocol used by the Acurite 592TXR and the 5-n-1 weather station are very similar. The weather station's messages are one byte longer, but they are basically the same with the same RF signaling characteristics.

Remotely monitor Refrigerator / Freezer temperature with Acurite 986 and rtl_433 (rtl-sdr)

I suspected the thermostat in my basement refrigerator was going bad, so I picked up an Acurite 986 refrigerator and freezer remote thermometer.  The display unit will give alarms if the temperature goes out of range.

I wanted a better picture of what was going on so I figured out the Acurite's 433 mhz protocol for the 986 sensors. I've added support to rtl_433. The pull request was merged November 20th, 2015.

Now I pump the data into rrdtool and see what's going on. I now see how long and often the compressor is running, and how long it times to warm up between cycles. The spikes are the defrost cycles.

Now I can also monitor/get alerted when I'm out of the house.

I'm pretty happy with the Acurite 986 display and temperature sensors even without the rtl_433 decoding.

Acurite 00986 Refrigerator / Freezer Thermometer Protocol

• Includes two sensors and a display, labeled 1 and 2, by default Sensor 1 - Refrigerator, 2 - Freezer.
• Data format: Pulse Position Modulated (PPM), 5 bytes, sent twice, no gap between repeaters
• Start/sync pulses: two short, with short gaps, followed by 4 long pulse/gaps.
• Data Format - 5 bytes, sent LSB first, reversed
• TT II II SS CC
• TT - Temperature in Fahrenehit
• integer, 
• MSB = sign. Encoding is "Sign and magnitude"
• II - 16 bit sensor ID changes at each power up
• SS - status/sensor type
• 0x01 = Sensor 2 (
• 0x02 = low battery
• CC = CRC (CRC-8 polynomial 0x07, little-endian) 

I was able to easily figure out the CRC with CRC RevEng..