The Modular WifiModem64

Posted on by
3

I’ve been playing with the ESP8266 since late 2014 and it was love on first sight: so many possible uses for such a small device at such a low price tag. And very early on I thought: wouldn’t it be great to build a WiFi “modem” from this? That shouldn’t be too hard. But I didn’t find the time to pursue the idea then. When I remembered again this summer, I was not surprised but still excited to find that others had had the same idea and hadn’t been as lazy as me.

Alwyz’s instructions on how to build such a device couldn’t be easier! I followed them and it worked like a charm. For the next months, my setup then looked like variations of this:

IMG_4236
Continue reading →

SD2IEC Revisited

Posted on by
5

When I discovered the MMC2IEC / SD2IEC project by chance back in 2009, it made me dig up again my soldering iron and electronic components after many years of disuse. I built myself one of those devices on a prototyping board and had a lot of fun doing so. It was the first time that I got involved with micro controllers and I learned a lot in the process.

Now, many years and projects later, I was looking for an excuse to try out KiCAD and to learn how to design my own boards using it. I had already ordered a small PCB I found on the net as a proof-of-concept to see if the Gerber files I produce would result in working boards. When they turned out just as expected I was eager to create something myself. This was the perfect opportunity to revisit the subject and make myself a brand new SD2IEC.

I wanted the design to be based on Shadowolf’s latest version but also make my own additions and changes:

  • The board should be able to tap into the cassette port of the C64 for power supply.
  • It should be board for external use with proper connectors just like my first build.
  • All components should be cheap to buy from Chinese suppliers.

So, this is the first prototype of what I came up with. I call it the “SD2IEC pluggable”:

IMG_4186
Continue reading →

OpenWRT and the Zsun Card Reader

Posted on by
10

During the last few weeks since my first post about the Zsun WiFi Card Reader I learned a few things that I haven’t documented yet.

After I was able to confirm that my device has indeed PCB v2 but that flashing should work just the same, I tried the simple method described here:

  1. Insert a FAT formatted micro SD card into the reader and plug the reader into a PC (running Windows, in my case). The card should be assigned a drive letter, say “J:”.
  2. Connect to the WiFi access point created by the reader.
  3. Open http://10.168.168.1:8080/goform/Setcardworkmode?workmode=0
  4. Open the drive/card in the file explorer, create a new folder named “.update.” and copy the SD100-openwrt.tar.gz archive into it.
  5. Open http://10.168.168.1:8080/goform/upFirmWare – this should return status code “2”.
  6. Wait patiently for the described LED flashes!
  7. Connect to the new access point called “OpenWRT”.
  8. Open https://192.168.1.1/cgi-bin/luci and configure OpenWRT.
zsun13

This worked like a charm (a big thanks to Warsaw!), but only 5 minutes later I managed to lock myself out with a bad WiFi config. Great. So I went ahead and soldered leads to the serial headers. But while I was able to receive and read the console output just fine I had no success sending any input to that console. Only today I learned that PCB version 2 is missing a jumper that needs to be connected in order to enable serial RX. Connecting this jumper has exceeded my meager soldering skills so far, though.

zsun18

Fortunately, I learned another fact from a helpful comment on my previous post: By inserting or removing the SD card during boot, OpenWRT can be put into fail-safe mode that will reset the configuration. I kept inserting and removing it in quick succession for about 10 seconds in order to get the timing right. Now I’m able to connect to the WiFi again!

Update:
One of the images is showing an Ethernet cable attached directly to the board. This did not work for me and trying it was somewhat naive. It’s been brought to my attention that this might damage the SoC, too. If resetting an OpenWRT installation as described above is not enough, the best way to un-brick the device seems to be through the serial console as described in the comments.

 

zsun10
zsun17
zsun16
zsun15
zsun14
zsun13
zsun12
zsun11
zsun18

[Show as slideshow]

The Zsun WiFi Card Reader

Posted on by
5

I’m not sure where I read first about the $8 Zsun WiFi Card Reader and the attempts by the people at Warsaw Hackerspace to flash it with their port of OpenWRT. It made me curious, so I went ahead and ordered a sample. Shipping from China took a while but I received the tiny gadget yesterday.

zsun08

So far I could confirm the documented root access to the stock firmware via telnet on port 11880 using the password “zsun1188”. I have not tried flashing OpenWRT yet as I am not sure which of the at least two different PCB versions I got. Could anyone give me a hint on this?

zsun01
zsun02
zsun03
zsun04
zsun05
zsun06
zsun07
zsun08

[Show as slideshow]

The Fancy Lantern Stick

Posted on by
5

I’m not sure about other parts of the world, but back here in Germany we’ve got a tradition called Laternelaufen. It involves lanterns, preferably home-made from cardboard and colored paper, lantern sticks, and a bunch of happily singing children. And of course, it requires a way of lighting the lanterns. Traditionally, this is accomplished by the use of burning candles which are cheap and actually looking great, but will also ever so often result in the lanterns themselves catching fire. So, for many years there have been battery powered lantern sticks featuring a small light bulb on the upper end.

IMG_4285

My daughter is very much looking forward to this year’s Laternelaufen events. What a great excuse for myself to get started on a small new project, the Fancy Lantern Stick! Here’s the list of major ingredients:

  • 20cm of PVC tubing 40mm in diameter, normally used for in-house plumbing
  • 50cm aluminum pipe, 6mm in diameter
  • 1 small piece of wooden board, roughly 15mm strong
  • Acrylic spray paint, the colors of your choice
  • Clear lacquer spray
  • 1 Arduino Pro Mini
  • 1 5V Step-up power converter
  • 1 Battery holder for 2 AA sized batteries
  • 8 WS2812B LEDs on separate tiny boards
  • 1 Switch
  • 1 Push-button
  • An assortment of wires, headers and connectors
  • Hot glue

When switched on, the Arduino will produce yellowish-white light from the 8 LEDs and simulate the moderate flickering of a candle flame. The red push-button on the handle triggers special light effects to show off.

The source code for the Arduino sketch is available on Github, and I’ll try to add a couple of photos showing the finished stick once I find the time and manage to borrow it back from my daughter.

Update:

I did manage to take a few photos of the finished stick today and added them to the gallery. Also, if there is enough interest I could supply more detailed information on how to build one of these, of course.

 

IMG_4270
IMG_4271
IMG_4272
IMG_4273
IMG_4274
IMG_4275
IMG_4288
IMG_4395
IMG_4399
IMG_4276
IMG_4277
IMG_4278
IMG_4279
IMG_4280
IMG_4282
IMG_4284
IMG_4285
IMG_4286

[Show as slideshow]

Converting .mysql_history Files to New Format

Posted on by
Reply

When I upgraded one of my servers from Fedora 20 to 21 recently, I noticed that – among a few other issues – the command line history of my mysql client was missing. Too me, this is valuable information and documentation, even. So I investigated and found, that the file format for the .mysql_history seemed to have changed and the client had just discarded my old data. The new file now contains various characters (including ‘space’) in octal notation and it starts with a special marker line:

_HiStOrY_V2_

I assume that this change might have been caused by either MariaDB or Fedora itself having switched from readline to using libedit.

#!/usr/bin/env php
<?php
$oldData = file($argv[1]);
foreach ($oldData as $line) {
    readline_add_history($line);
}
readline_write_history($argv[2]);

The PHP package that comes with Fedora 21 seems to be using the same library. So, after restoring my old .mysql_history from backup it was easily converted to the new format using but a few lines of PHP code:

./convert_history.php ~/.mysql_history.bkp ~/.mysql_history

 

 

Wireless Sensor Network, Part 2

Posted on by
2

Still trying to save my batteries

By now it is time for at least an intermediate update on this project. In the meantime I have indeed revised the sensor boards by adding a switching transistor controlled through one of the remaining digital pins on the ATmega. The firmware was modified, and it will now power down the attached sensors before entering sleep mode. Disappointingly, this resulted in a battery lifetime extended by no more than roughly 10%.

graph-vcc-nimh-2

On a mostly unrelated note, the voltage graph now looks “stepped” when compared to the previous one. This seemed to be a direct result of switching from maniacbug’s original driver for the RF24 module to the one newly optimized by tmrh20. I’ve got absolutely no clue why this would affect the voltage measurement against the bandgap reference, but there it was. If you can shed some light on this, please leave me a comment.

The next thing I tried, somewhat desperately, was to reduce the number of data samples by increasing the sleep time from 1 minute to 5 minutes. This had no discernible effect on battery life-time. But at least it leads to the conclusion that I need to further investigate power consumption during sleep mode.

IMG_1442

So, just assuming that it was the sensors that were draining the batteries in sleep mode turned out to be a bad idea. Now I really need to replace my crappy 7€ multimeter with something a little more precise that will allow me to actually measure which part of the circuit is drawing which amount of current.

IMG_1442
IMG_1443
IMG_1445
IMG_1446
IMG_1447
schematics11
perfbottom_v11
perftop_v11
graph-vcc-nimh-2

[Show as slideshow]

Wireless Sensor Network, Part 1

Posted on by
2

With all components finally having arrived from China, I built the first couple of wireless sensors a few months ago. They are using the cheap nRF24L01 transceiver modules for data transmission based on the RF24Network network layer. I’m using a Raspberry Pi with the transceiver module directly connected to its GPIO pins as the root node. The sensor nodes are controlled by an ATmega328 microcrontroller flashed with the Arduino firmware for convenience.

IMG_3806

Each sensor node currently features a DHT11 humidity sensor, a DS18B20 digital thermometer, a BMP180 barometric pressures sensor and it’s powered by three AA cells. The controller spends most of its time in power-saving sleep mode, waking up to send a data packet about every minute. Each packet contains the readings from the three sensors as well as the battery voltage as determined against the bandgap reference.

The setup is far from final. For one, I’m still not sure how to store the data. Currently, it is just logged into a text file with an occasional and experimental import into OpenTSDB. I haven’t really come to trust OpenTSDB since I haven’t found a suitable and convincing way to backup the HBase data, yet.  Also, I might still replace the Raspberry Pi root node with an Arduino based MQTT relay.

graph-vcc-nimh-1

First though, the power consumption of the sensor nodes needs improving. When I started out I was hoping for each node to run for close to a year on a single set of batteries. As you can see in the graph above, with the current design a set of three NiMH batteries with low self discharge lasts for no more than 6 weeks. What comes to mind in order to improve this, is to switch off the sensors and the transceiver in between samples. That is probably what I’ll try next. Please let me know if you’ve got any other ideas!

 

 

IMG_3801
IMG_3802
IMG_3803
IMG_3806
IMG_3809
IMG_3811
IMG_3813
IMG_3814
IMG_3816
IMG_3818
perfbottom_v1
perftop_v2
graph-vcc-nimh-1
schematics1

[Show as slideshow]

Minimal Arduino using an ATmega88

Posted on by
5

In preparation of the quest to build my own wireless sensor network I spent some time in getting a minimal Arduino up and running based on the ATmega8 chip. It was not before I finally succeeded that I realized it would be of no use in this case, because the ATmega8 lacks the ability to trigger an interrupt handler through its watchdog timer. So, I wouldn’t be able to use its power down sleep mode.

ATmega88 using internal clock

I then found a couple of ATmega88 chips in my stockpile, which aren’t subject to this limitation. Fortunately, setting this one up as a minimal Arduino turned out to be much the same. I mostly followed an existing guide, but added the Optiboot bootloader to the mix.

I first needed to compile the bootloader for the use with the internal osciallator at 8Mhz. So I added the following lines to arduino-1.0.5-r2/hardware/arduino/bootloaders/optiboot/Makefile:

atmega88_8: TARGET = atmega88
atmega88_8: MCU_TARGET = atmega88
atmega88_8: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=19200'
atmega88_8: AVR_FREQ = 8000000L
atmega88_8: LDSECTIONS  = -Wl,--section-start=.text=0x1e00 -Wl,--section-start=.version=0x1ffe
atmega88_8: $(PROGRAM)_atmega88_8.hex
atmega88_8: $(PROGRAM)_atmega88_8.lst

I limited the baud rate to 19200 as greater values turned out to be less reliable in my setup. For this to work, I had to explicitly disable SOFT_UART in optiboot.c:

/* Switch in soft UART for hard baud rates */
#if (F_CPU/BAUD_RATE) > 280 // > 57600 for 16MHz
#ifndef SOFT_UART
//#define SOFT_UART
#endif
#endif

With that you can build the bootloader by running make atmega88_8 or omake.bat atmega88_8 on Windows in that same directory.

Next, I added the new Arduino type to arduino-1.0.5-r2/hardware/arduino/boards.txt. It should have been possible to add the board definition to a boards.txt file below the sketchbook directory but that did not work for me and the current version of my Arduino IDE.

atmega88_8.name=ATmega88 Optiboot (8MHz internal OSC)
atmega88_8.upload.protocol=arduino
atmega88_8.upload.maximum_size=7680
atmega88_8.upload.speed=19200
atmega88_8.bootloader.low_fuses=0xe2
atmega88_8.bootloader.high_fuses=0xdf
atmega88_8.bootloader.extended_fuses=0x00
atmega88_8.bootloader.path=optiboot
atmega88_8.bootloader.file=optiboot_atmega88_8.hex
atmega88_8.bootloader.unlock_bits=0x3F
atmega88_8.bootloader.lock_bits=0x0F
atmega88_8.build.mcu=atmega88
atmega88_8.build.f_cpu=8000000L
atmega88_8.build.core=arduino
atmega88_8.build.variant=standard

Finally, with the ISP connected, I installed the new bootloader using the Aduino IDE and can now upload sketched through the serial connection.

There seems to be one annoying issue left though. When the compiled sketch size is getting close to the limit of 7680 bytes the upload will fail with an error message. If anyone can shed some light on what I might have missed here, please leave me a comment.

IMG_3798
IMG_3799
IMG_3800

[Show as slideshow]