Entries by Dan

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

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

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.

One way not to print envelopes – HP ePrint

I somewhat recently acquired an HP Officejet Pro 8620. I’m relatively happy with the printer but there is one problem with it. The internet/cloud enabled printing functionality is garbage. HP puts its ePrint service in-between your printer and Google Cloud Print. In the process it removes many features like: the ability to change quality and to set the paper size. This means that devices like Chromebooks can not ever print envelopes to my printer via the supported cloud printing functionality.

I have found a solution but its sub-optimal since it depends on another computer in my house. I installed the HP printer drivers on my Linux workstation and then shared that installed printer with Google Cloud Print.

The result is full featured access to my printer but only when both my printer and my Linux workstation are on. I would expect this to also work with a Mac or Windows.

The only way to get free play on Vs. Tetris

I recently added Vs. Tetris to my Nintendo Red Tent. I was dissapointed to find there were no dipswitch settings to make it free to play like all of my other games.

I created 2 replacement ROM images which turn the game in to freeplay all the time and posted them to a github repository.

To use this you’ll need access to an EPROM programmer (and an eraser if you want overwrite the existing chips in your system). I used an inexpensive MiniPro TL866CS programmer and UV eraser off Amazon for my ROMs.

Saving high scores on the XXX in 1 JAMMA boards

This is a two for the price of one post. This will go over adding an RW partition to the SD card and how to use it to store your highscore files.

Adding an RW partion


  • A computer running Linux
  • SD card adapter
  • An SD card with your arcade OS loaded on it(Use a backup copy for this!)


  1. Connect your SD card (Did I mention that you should use a backup yet?)
  2. Run dmesg to figure out what the device name of your sd card is
  3. Create the partition
    fdisk /dev/<sd card device>
    n for add new partion
    enter for the default starting cylinder
    enter for the default ending cylinder (or specify a size if you don't want to fill up the rest of the sdcard with this partition)
  4. Format the partition:
    mkfs.ext2 /dev/<sd card device partition 4>
  5. Its helpful to have a mount point for each of the partitions on the card so its easy to move files around:
    cd /mnt
    mkdir one two three four
  6. Mount the third partition of the sd card. This contains most of the base OS and startup scripts
    mount /dev/<sd card device partition 3> /mnt/three
  7. Add a mount point directory for the new rw partion we made:
    mkdir /mnt/three/sdcard-rw
  8. Now an edit to the startup script to mount the rw partition:
    vim /mnt/three/etc/init.d/rcS (or whatever editor you like)
    Add a line after the line that says “System Starting”:
    mount /dev/mmcblk0p4 /sdcard-rw
  9. Save your edits
  10. umount /mnt/three

Now when your board boots you’ll have a directory which is mounted read-write at /sdcard-rw. The next section will go over how to move the highscores over to there.

Saving highscores

This covers the general concept for the 412 in 1. This works for the games that run with xemu (which is xmame) and aemu which is another MAME variant with different build options.


  • A read-write partition setup as described above
  • A copy of hiscore.dat from here. This is needed since its not included in the image.
    • Unzip the archive and get the hiscore(pre_mame0133u1).dat file this gets used the rest is not.


  1. Mount the new rw partition:
    mount /dev/<sd card partition 4> /mnt/four
  2. Mount the emulators partition:
    mount /dev/<sd card partition 2> /mnt/two
  3. Mount the base OS partition
    mount /dev/<sd card partition 3> /mnt/three
  4. Now make some directories to store the data for each emulator on the image:
    mkdir /mnt/four/xmame
    mkdir /mnt/four/aemu

  5. Make a directory for the hiscore.dat file (This directory is already setup in the xmame config)
    mkdir -p /mnt/three/usr/local/share/xmame
  6. Move the hiscore(pre_mame0133u1).dat to the directory as hiscore.dat
    mv hiscore(pre_mame0133u1).dat /mnt/three/usr/local/share/xmame/hiscore.dat
  7. Move the highscore directories to the rw partition:
    mv /mnt/two/.xmame/hi /mnt/four/xmame
    mv /mnt/two/aemu/hi /mnt/four/aemu
  8. Create symlinks for those hiscore directories:
    ln -s /sdcard-rw/xmame/hi /mnt/two/.xmame/hi
    ln -s /sdcard-rw/aemu/hi /mnt/two/aemu/hi
  9. Move the nvram directories:
    mv /mnt/two/.xmame/nvram /mnt/four/xmame
    mv /mnt/two/aemu/nvram /mnt/four/aemu
  10. Create symlinks for the nvram directories:
    ln -s /sdcard-rw/xmame/nvram /mnt/two/.xmame/nvram
    ln -s /sdcard-rw/aemu/nvram /mnt/two/aemu/nvram
  11. Add a symlink for the hiscore directory for aemu:
    ln -s /usr/local/share/xmame/hiscore.dat /mnt/two/aemu/hiscore.dat
  12. Unmount all those partitions:
    umount /mnt/two /mnt/three /mnt/four

That’s covers everything but 19XX which uses a different emulator which I haven’t gotten to figuring out yet.

Changing the menu music on the XXX-in-1 JAMMA boards

To change the music on the XXX-in-1 JAMMA boards. You need a replacement mp3 file. For mine I used some chiptunes to keep with the theme.

  1. Get your SD card(or copy of your SD card) off the board.
  2. Mount the third partition on your machine. The file system format is ext2, this can easily be done on any Linux machine. It is possible with Mac OS and Windows but it requires a bit more effort.
  3. On the mounted partition replace the /usr/xrun/bg.mp3 file with the replacement mp3 file you’ve prepared.

This process has been tested with the vertical 276 in 1 and 355 in 1 boards.

While you’re in the /usr/xrun directory you’ll notice some other interesting files:

  • Images for the menu system
  • Sound effects (in .wav format) for coin, and menu movement
  • Config files for the menu system

Running horizontal games on the vertical 412 in 1 JAMMA board

This assumes you’ve already hacked the board so you can run arbitrary roms.

You can pass the -scale option to /sdcard/aemu/aemu which will stretch and squish a horizontal game to run on the vertical monitor.

This is not the best solution. However, it works and you can at least see the whole game screen.

Compiling for the 276 in 1 JAMMA board

These instructions show how to build binaries for the 276 in 1 JAMMA board. These instructions probably do work for the other XXX in 1 JAMMA boards that have an SD card on the board.

This is a bit of a crash course in cross-compiling. Before we dive in here is the objective: Get the build process for whatever you are building to use the compiler and libraries in the toolchain we will install. This might happen via changes to the Makefile, CFLAGS, LDFLAGS, or options to the configure script.

I ran all of these instructions on an install of Ubuntu 12.04(Precise Pangolin) on  32bit install. If you are using a 64bit install you will probably need to install the ia32-libs package via apt-get to make the cross compile toolchain work.


  1. Install the build-essential package: sudo apt-get install build-essential
    build-essential is a meta package which installs a few very common and always needed tools and libraries for compilation.
  2. Get the cross compile toolchain from the mini6410-debian project
  3. Extract the tar.gz file downloaded to root /: sudo tar xzvf arm-linux-gcc-4.5.1-v6-vfp-20101103.tar.gz -C /
  4. Add /opt/FriendlyARM/toolschain/4.5.1/bin/ to your PATH: export PATH=$path:/opt/FriendlyARM/toolschain/4.5.1/bin
    It would be a good idea to add this to your .bashrc or .profile

Build prerequisite SDL library

  1. Get the source for SDL 1.2 from the SDL project.
  2. Extract the source code: tar -zxvf SDL-1.2.15.tar.gz
  3. cd SDL-1.12.15/
  4. Run the configure utility with some extra options: CFLAGS=”-mno-thumb-interwork” ./configure –host=arm-none-linux-gnueabi –enable-static –prefix=/opt/FriendlyARM/toolschain/4.5.1 –disable-pulseaudio
    The option in CFLAGS was required to get the gcc compiler to not use certain assembly instructions the board doesn’t support. The –host option tells the configure script this is a cross compile for arm-none-linux-gnueabi. –enable-static means that all the dependencies for and resulting executables will be built-in. –prefix makes it install the resulting libraries and code in the location provided. –disable-pulseaudio does exactly what it says. I found that pulseaudio was not easy for me to get built so I dropped it since none of the original emulators used it.
  5. Run: make
    This does the compile. It will take bit to finish.
  6. Run: sudo make install
    This installs all the stuff built by make.
  7. Make a symlink for sdl-config: ln /opt/FriendlyARM/toolschain/4.5.1/sdl-config /opt/FriendlyARM/toolschain/4.5.1/bin/arm-none-linux-gnueabi-sdl-config
    This link is required so that when we are doing cross compiles that the sdl-config executable looks like it is part of the toolchain

Note that if you building anything other than AdvanceMame you might need other dependencies. These instructions intend to be a rough outline and not a script. Its very likely that they won’t work if anything is different.

Building AdvanceMAME

  1. Get the source for AdvanceMame.
  2. Extract it: tar -zxvf <filename>
  3. cd advancemame-1.2/
  4. Run the configure script with a bunch of options: CFLAGS=”-mno-thumb-interwork” LDFLAGS=”-L /opt/FriendlyARM/toolschain/4.5.1/lib/” ./configure –host=arm-none-linux-gnueabi –enable-static –enable-sdl –disable-kraw  –prefix=<SOMETHING IN YOUR HOME DIRECTORY>
    The LDFLAGS are needed to make sure the linker can find the libraries we installed for SDL. –enable-sdl makes sure we build AdvanceMAME with SDL support. –disable-kraw disables the raw keyboard input type since it doesn’t work right on the board. –prefix is the install target. Make a directory in your home directory to install to so its easy to get the entire install of AdvanceMame over to the SD card. Use this path for the prefix.
  5. Run: make
  6. Run: make install
  7. You have a complete install of AdvanceMame now in the prefix directory you specified. You can copy the contents of that over to your sdcard and use it.

I did not cover how to modify a Makefile for cross compilation because it is considerable more involved than just an option to configure. The short version is that you’ll need to go in the file and make sure it uses the libraries and utilities in the /opt/FriendlyARM/toolschain/4.5.1 directory instead of the ones on your system.

Cracking the 276 in 1 JAMMA board

Many of the emulators on the 276 in 1 board have checks to make sure the configuration hasn’t changed. These checks attempt to reboot the board and exit the binary. This is unhelpful if you are trying to swap out the roms/games on this board.

I’ve started to disassemble and patch the emulator binaries to remove these checks from them. I’ll post them here as I finish them. These all live on the second partition of the sd card in the location I specify.

276 in 1 binaries

clsemuv – This is the default emulator on the 276 in 1 and it did have a check.
xemu – This is emu1 in the games.conf file and is used for many games. It does not have a check so I have not patched or uploaded it.
cemu/cemu – This is emu2 in the games.conf file and is only used for a handful of games.

412 in 1 binaries

xemu – still unprotected(but different than the 276 version)
xrunmv – Game launcher menu – It *seems* that this is all that is actually required to be able to play any game you want. Start with this and swap out the other binaries as you decide you need to.

355 in 1 binaries


Please note that the provision of these binaries is sole for you to run roms which you are legally entitled to. This is not intended for piracy.

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


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:


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:


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:


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.