Ressurection of a WirelessThings OpenPi (from kickstarter)

Many years ago, I was handed one of the openpi kickstarter devices (see https://www.kickstarter.com/projects/wirelessthings/openpi-wireless-computer-for-inventors-makers-and) after Ciseco/Wireless things had gone under and my former boss had no further use for it. The dinky keyboard (and USB dongle) was promptly snaffled by a (now retired) colleage, and I had a brief play with the board, realised it was a single core CM1 board and kinda filed it away.

I'd dug it out semi-recently to see if it could be pressed into service to run info-beamer down at the local men's shed, but I decided it probably wasn't worth the hassle and back into the box it went. Cue a spot of bench-clearing and I decided to see if it could run a current OS and work (I want some sort of RF bridge to get the RF blinds into Home Assistant and that may be a use case).

Notes which may help others in future. 

WirelessThings website is long gone (there are some snapshots on archive.org) but https://github.com/WirelessThings/OpenPi/ still exists and has the schematics. Grab em if you need them. 

The warning about not being able to connect to a CM1 with `rpiboot` from a mac still seems valid, but it worked great from the standard pi I have on my workbench. I grabbed the current 32 bit Pi Os lite from https://www.raspberrypi.com/software/operating-systems/ then dd'd it over to /dev/sda (the openpi has 4GB eMMC onboard) as documented at https://www.raspberrypi.com/documentation/computers/compute-module.html#flash-compute-module-emmc. There was some slight faffing as new raspbian/Pi OS images don't create the user or allow ssh in by default. Fixed up by touching the 'ssh' file while I had the image mounted on my desktop pi ("mount /dev/sda1 /mnt" for the boot partition, /dev/sda2 is the actual root volume) - I tried to be clever and edit the cloud-init files to get it to auto-update and pull my public keys from GitHub but it bombed out when loading the new video drivers. That was fixed by editing out the 

# Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d
#max_framebuffers=2

section in config.txt and rebooting. 

I'm using a generic USB to ethernet (Realtek 8512) dongle rather than wifi, which got the device online fine, but I coun't ssh in even after adding my public keys to the pi (created by cloud-init) user. Turns out it helps if you don't have a shell of /usr/sbin/nologin.

I was hoping there'd be some magic would happen with the on-board eeprom to detect the hardware and set things up, but nope. You're going to need to edit the config.txt and at least add i2c and dtoverlay=i2c-rtc,ds1307 for the clock.

I grabbed the overlay dts from github and compiled (complete with warnings):

root@pi-cm1:~# dtc -o /boot/overlays/openpi.dtbo  openpi-overlay.dts
openpi-overlay.dts:47.17-27: Warning (reg_format): /fragment@2/__overlay__/spidev@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
openpi-overlay.dts:55.17-27: Warning (reg_format): /fragment@2/__overlay__/spidev@1:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/boot/overlays/openpi.dtbo: Warning (pci_device_reg): Failed prerequisite 'reg_format'
/boot/overlays/openpi.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
/boot/overlays/openpi.dtbo: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
/boot/overlays/openpi.dtbo: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
/boot/overlays/openpi.dtbo: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
openpi-overlay.dts:45.21-51.15: Warning (avoid_default_addr_size): /fragment@2/__overlay__/spidev@0: Relying on default #address-cells value
openpi-overlay.dts:45.21-51.15: Warning (avoid_default_addr_size): /fragment@2/__overlay__/spidev@0: Relying on default #size-cells value
openpi-overlay.dts:53.21-59.15: Warning (avoid_default_addr_size): /fragment@2/__overlay__/spidev@1: Relying on default #address-cells value
openpi-overlay.dts:53.21-59.15: Warning (avoid_default_addr_size): /fragment@2/__overlay__/spidev@1: Relying on default #size-cells value
/boot/overlays/openpi.dtbo: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
/boot/overlays/openpi.dtbo: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'

One reboot later (after enabling my overlay in config.txt) and it's not obviously better. 

Features this carrier is supposed to have:

SRF RF board

This was an in-house module by Ciseco (now defunct) - I suspect finding docs on this will be 'Fun' - No idea yet how to test it. 

Bluetooth LE 

Using a HM-10 module. Kickstarter updates indicates it may be on a second serial port as the only one visible at boot is

20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 AXI 

 

Datasheet at https://people.ece.cornell.edu/land/courses/ece4760/PIC32/uart/HM10/DSD%20TECH%20HM-10%20datasheet.pdf 

ah gettingstarted has this note

dtoverlay=uart1,txd1_pin=40,rxd1_pin=41 

IR Receiver

i2c - LIRC config needed but config.txt suggests
dtoverlay=lirc-rpi,gpio_in_pin=35,gpio_out_pin=33

then complained about lirc-rpi being deprecated, so changed to 

dtoverlay=gpio-ir,gpio_pin=35

note on the schematic gpio33 is 'ir_out_nc' which ties in with there being no IR transmitter 

 Datasheet at https://www.vishay.com/docs/82496/tsop752w.pdf 

lirc package wanted to bring in hundreds of dependencies so not investigated more but this looks hopeful

[   57.886350] Registered IR keymap rc-rc6-mce
[   58.042885] IR RC6 protocol handler initialized
[   58.104101] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver@23/rc/rc0
[   58.104738] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter
[   58.105325] input: gpio_ir_recv as /devices/platform/ir-receiver@23/rc/rc0/input3
[   60.170102] mc: Linux media interface: v0.10
 

RTC

nice and simple

dtoverlay=i2c-rtc,ds1307

(I haven't fitted a battery so still dependent on chrony to set clock)

 

[   78.005555] rtc-ds1307 1-0068: registered as rtc0
[   78.033781] rtc-ds1307 1-0068: setting system clock to 2026-05-10T13:12:38 UTC (1778418758)  

Temp sensor

i2c based https://www.ti.com/lit/ds/symlink/tmp100.pdf

apparently in the kernel under lm75 hwmon driver

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/hwmon/lm75.c?h=v6.12.87

however adding dtoverlay=i2c-sensor,lm75 to config.txt and rebooting isn't working:

[ 76.812881] lm75 1-004f: supply vs not found, using dummy regulator
[ 77.016199] lm75 1-004f: probe with driver lm75 failed with error -121 

Then I noticed the schematic has both add0 and add1 tied to ground, so address is 0x48 - one quick bodge to the config.txt

dtoverlay=i2c-sensor,lm75,lm75addr=0x48 (possibly a straight addr=0x48 would work too?)

reboot and looking good

[   77.814608] lm75 1-0048: supply vs not found, using dummy regulator
[   77.864130] hwmon hwmon2: temp1_input not attached to any thermal zone
[   77.864210] lm75 1-0048: hwmon2: sensor 'lm75'
 

andrew@pi-cm1:~ $ cat /sys/class/hwmon/hwmon2/name
lm75
andrew@pi-cm1:~ $ cat /sys/class/hwmon/hwmon2/temp1_input
22500
andrew@pi-cm1:~ $

 

GPIO Button

 

HAT EEPROM

 

GPIO Headers on the underside 

That's a future project :-) 

 

.. to be continued 

 

 

 

Energy metering update

 This is an update to my previous post (https://blog.elwell.au/2024/09/tomznhiking-dds238-2-rs485-energy-meter.html) as I've swapped out the bulky wemos + separate RS485 module for a din-rail ready waveshare esp32-s3 based device (see https://www.waveshare.com/ESP32-S3-RS485-CAN.htm) which looks much better and can even go in the switchboard. It takes 7-36v supply voltage so any of the mean well din PSUs work well depending what else is required.

Anyway, my git repo (https://github.com/Elwell/ESPHome-DDS238) has a new branch (esp8266) for the legacy hardware - updated slightly as I'd omitted the 'state_class' previously and it wasn't working with the new energy dashboard - and the new hardware is in the 'main' branch.

Too many buttons

 I have a standard ham licence (VK7HPC) and am currently poking at a Retevis RT95 (same as the Anytone AT-778UV). As I'd like to use it for digital modes, Steve (KM9G) over at Temporarily Offline Ham Radio has a playlist where he's investigating the pinout to make a microcontroller APRS interface, however he's not yet mentioned how to memory jump or enter a direct VFO frequency. Sure CAT control would be nice, but this radio's under 200 AUD delivered, so that's unlikely to happen. 

So, the manual hints at "keypad serial data" on pin8 so with a bodge together of 2 cat5 outlets, some wire and a logic analyser, lets see what we can find...

Force of habit means I used the T568A colours, so the from the pinout shown here you'll need to swap the orange/green pairs round. 

Anyway: Up, Down, PTT all get pulled to ground when pressed as expected and there IS some serial data on pin8, now I need to sample and collect more...

Update

In a stroke of good fortune, it appears to be plain ascii at 9600 baud. Pressing each key in turn spat out AL~K1, AL~K2, ... AL~Kx where x is 0-9,*,#,A-D and / (the latter being the toggle for A/B input)

Next up will be introducing it to little bobby microphone and seeing if I can send commands to the radio directly from a microprocessor

Particulate measurements near bushfires

Back in the 2019 Tasmanian bushfires we were lucky enough to be the other side of the Huon River from the fireground,  however we had a LOT of smoke (compare the photo below to the street view image)

We were also lucky enough to take part in a Huon Valley trial to compare HEPA filter systems which used a pair of CSIRO Smoke Observation Gadgets (further details on these units in Sensors 2021, 21(21), 7206; https://doi.org/10.3390/s21217206) to log the air quality (pm2.5 and pm10 measurements) inside and out. 

It's now 2025, and while we've been very lucky compared to the US and mainland Australia, we now have a bushfire nearby (~6km from our house) that contains the following advice:

Residents should be aware that smoke and ash may be visible in the Channel area over the coming weeks, and anyone who is at higher risk from smoke should enact their personal health plans.

So, it's time to DIY some new smoke sensors! (I would just rely on the excellent BLANkET network already in place in Tasmania, but there aren't any downwind of the current fire)

Hardware

I already have a pair of PMS7003 sensors unused in a 'future projects' box, so we'll use them. They are supported by esphome, so using an esp32/esp8266 with them seems a simple choice

Mine (located in Kettering) will use a wired esp32 (because POE makes that simple), and I'll see if I can get one mounted at the Channel Men's Shed in Margate which will need to use wifi

I don't have a nice shiny 3d printed enclosure, so it'l use something like an old yoghurt tub to weatherproof them.

Build

.. To Be Continued at the weekend :-)

Word of mouth Skye History

Many years ago we lived in the Old Manse in Waternish, Skye. If you look on the maps, you'll spot that unlike nearly all the other houses on the road, the Manse has house *directly* opposite, blocking the view over Loch Bay and the Minch. See also street view. 

The backstory to all of this is that the Minister at the time had fallen out with the Factor / Laird and when the health board were looking to build a 'nurses bungalow' the only land available in the entire area was that plot, directly in front of the Manse.

As with all the best tales, the twist was that when the factor became old and decrepit, the only person who'd take him in was ... the minister, so he spent his final days looking out at the non-view.

(blogged as a response to https://www.youtube.com/watch?v=p8fOJdmSbdU)

Tomzn/hiking DDS238-2 rs485 Energy Meter with ESPHome for Home Assistant

There seem to be several branded versions of this cheap 2 unit wide energy meter available online from the regular stores. I have a 'tomzn' branded on purchased several years ago and monitored the shed power in our last house. It's been relocated to the new place and is now in the switchboard in the shed^Wart studio in the garden.

Interfacing to home-asisstant

There are a pair of RS485 terminals and second pair provide pulse output. I got the sparky to run a short length of RS485 cable to a convenient location near a GPO for a USB power supply. I then have this connected to a cheap MAX485 module and on to an ESP8266 using the hardware serial port pins. I'm driving the max485 breakout with 3.3v so I don't need to worry about level shifters.

It's using a full-size Wemos D1 R2, purely because that's what I had on hand. As I'm using the serial port pins for connection to the RS485 converter, unplug before serial flashing. (OTA updates are fine)

My current software polls the meter every 5 seconds (note the RX/TX leds lit on the breakout, and the phone symbol on the meter LCD when this happens) https://github.com/Elwell/ESPHome-DDS238 has a very similar config to production

and you end up with this on the esphome and home assisstanr web interfaces

 

New House, New Blogpost

 Well, it's been a while since I last posted an update - shorter snippets are likely to be on Mastodon (https://mast.hpc.social/@Elwell) so figured I'd scribble something down.

We sold The Roundhouses in Sept 2023 and have moved "Over East" to Kettering. Now that I have loads of spare time (ha ha ha ha) I've joined the local Mens Shed which has an active ham group (VK7CMS). This and a discussion on the REAST discord about packet /APRS got me thinking about how to packetiffy a foxhunt. First thoughts scribbled at https://github.com/Elwell/ham-geocache