Entries filed under Hardware

Digging in to the La Crosse C84428 Weather Station

For Christmas I received a home weather station which has a few IoT type features. Of note are: pushing sensor data to a La Crosse hosted application, NTP based time sync, and collection and display of weather report data from the National Weather Service APIs.

What I want is to be able collect all the sensor data for myself so I can make my own graphs.

With a Raspberry Pi I’ve setup a man-in-the-middle access point that I’ve connected my test phone and weather base station to.

On the Pi I’m running mitmproxy with iptables rules to intercept traffic to port 80 and 443 to the proxy.

Doing this I’ve noted the following things:

  1. Internet connectivity is powered by an ESP8266
  2. All of the APIs that it interacts with are hosted on Google Cloud (more of this to come in a future blog post)
  3. The ESP8266 does *not* perform a proper SSL certificate verification before shipping its sensor data.
  4. Sensor data gets shipped to the server in what looks like a string of hex data. Example: 2B52810E24B01D1C or 0BE6250EAAAAAA000AAAC6

My guess is that a simple https server with a self-signed certificate could easily intercept and maintain functionality through to the hosted API.

The primary challenge now is decoding the hex data shipped to the server.

Temperature / Humidity Sensors

I logged a pile of data and found some related work (note this one even includes the constant I discover myself later on).

The data appeared to be hexadecimal numbers and based on other prior decoding efforts I expected the temp to be transmitted in Celsius.

Here is one Data string from my sensor with my analysis so far

2B528108295020D7
2B5281 08 295 0 20 D7
Station ID Counter increments by two until 0E then rolls over Temp data Padding Humidity CRC-8

This is my guess for structure.

This data corresponded to a temp of 79F and 32% humidity.

Getting the Temp.

295 hex converted to base-10 is 661. 79F in is 26.1C.

(26.1*10) => 261

661 – 221 = 400

Base10 temp data = (Tc*10) + 400

Convert the base10 value to hex

I validated this conversion is correct against another reading.

Getting the humidity

This is very straightforward. See the ’20’ byte above. That translates directly to 32 which was the reading at the moment.

Checksum (CRC-8)

This took me a while even though I found the the final answer on a post about the TX-29 protocol. I struggled to find an implementation of CRC-8 which I understood and could get it to compute the right answer.

I was able to use the reveng tool to accomplish a successful CRC check. I ran the following command:

$ ./reveng -a 4 -w 8 -b -p 31 -c 2B528108295020
d7

Note I stripped the last to characters off the original data from above and that the command returned d7 as I expected.

This means that its a CRC calculation with 4 bits per character, 8 bits in its register, big-endian, and uses a polynomial of 31.

My next step for this is to write a python implementation to parse these packets.

Hacking the 276 in 1 JAMMA board

TL;DR: Someone else has done this already go here.

My super wife bought me a modified Ms Pacman cabinet which has the 276 in 1 JAMMA board in it now. I noticed immediately it had an SD card on it and needed to know if it could be modified in anyway. This post will grow over time as I find new details.

Hardware info

The JAMMA board appears to have an ARM CPU based on the few binaries I looked at.

SD Structure

Three partitions. 1 is /boot, 2 contains some configuration and start up scripts, and 3 is / with a typical Linux file structure.

Partition 1

TODO

Partition 2

Lots of interesting things here

  • clsemuv – looks to be a build of the GP32 version of MAME
  • xemu – some sort of binary based on strings it seems to be a combination of sdlmame and pinmame
  • xhidev – another binary – looks like its used to control the other binaries
  • xrunmv – yet another binary – this seems to be a build of the LemonLauncher.
  • run.sh – tiny bash script which runs xrunmv
  • roms/ – symlink to /usr/roms – this directory is present on parition 3
  • nvram/ – directory containing .nv files for each ROM file
  • wavs/ – symlink to /usr/wavs
  • xrun/ – symlink to /usr/xrun

Partition 3

This seems to be the bulk of the Linux installation. It has all the usual unix directories here.

From some files in etc/ I think that partition 2 gets mounted at /sdcard during boot

Backing Up Your SD Card

The SD card has a special bootloader which needs to be “fused” with the SD card after it is imaged otherwise the system won’t boot.

To do this you need a few things:

  1. SD-Flasher: Get it from here: https://code.google.com/p/mini6410-debian/
  2. The correct SDBoot image for your JAMMA board. Some folks at the Arcade Museum forums have extracted these from their SD cards and posted them. There are 2 versions which I have uploaded here for your convenience. SDBoot 1.1 or SDBoot 1.21
  3. An image of your existing SD Card: Do this with DD or the imaging tool of your choice
  4. A new SD card – You might be able to use a larger or different SD card but I bought the identical card that came with my board on Amazon.

To do it:

  1. Image your arcade image on to the new SD card (I did this with dd)
  2. Start of SD-Flasher
    1. Pick the SDBoot bin file
    2. Click Scan!
    3. Pick the right card out of the list
    4. Click Fuse
  3. You’re done!

Previous Work

Some folks on the Arcade Museum forums have actually done all this work already. One of the members there summarized most of the work on this thread:

http://forums.arcade-museum.com/showthread.php?p=2417021#post2417021

Using EZCap EzTV668 DVB+ receiver for SDR on Mac OS X 10.7

There has quite a bit of buzz about the RTL-SDR project that is going on over at reddit on the rtl-sdr subreddit. Most of it has been about using the RTL2832/e4000 devices under Windows and Linux. Since I primarily use Mac OS I decided to cobble together the various hints of other people who have successfully used the devices on Mac OS and document them in a gist on github:

https://gist.github.com/2874757

Update: After some feedback on reddit for the previous gist I decided to revisit my build to that I would have a more up to date version of GNURadio. After much hacking I came up with these directions for getting GNURadio 3.6.0 working on 10.7:

https://gist.github.com/2eb4ff8e240164d0f751

After following those directions you’ll want to then install the rtl-sdr driver and then gr-osmocomm so that you’ll be able to use the RTL tuner with gnuradio.