Tag: raspberry pi

Posted on

docker-compose.yml for 1x MongoDB container plus 1x data volume container

I’m starting to dabble with docker-compose to link up some container goodness. If you’ve followed my other Docker related posts the past couple of days (here), then you might have noticed that I have something Raspberry Pi related cooking 🙂

Although I’ll have to redo these with a Pi compatible base images, to get MongoDB running in one container with a separate data volume container is actually pretty simple. Here’s what I ended up with. To start it up, ‘docker-compose up -d’ and you’re up and running (copy this to docker-compose.yml):

mongodata: 
 image: mongo:3.2
 volumes:
 - /data/db
 entrypoint: /bin/bash
mongo: 
 image: mongo:3.2
 volumes_from:
 - mongodata
 ports:
 - "27017:27017"
Posted on

Spring Boot REST app in a Docker Container on the Raspberry Pi

Docker on the Raspberry Pi? Sure, with help from Hypriot who provide an iso image ready to go, getting docker up and running on the Pi is as simple as burning their image to an sd card and booting it up. Ok, so that part is simple.

Building an image to run on the Pi is not as straightforward as it sounds. Well, it’s no more complicated than building an image from a Dockerfile, but given that the Pi is ARM based and not x86, you have to build an image that is built/compiled with executables/libraries for ARM.

This makes complete sense when you think about it, you’re not going to get an image containing x86 executables and libraries to run on a Pi, but it’s rather sad that it isn’t possible to build an image for example from my Mac and and I can run on my Mac, or Linux, or on the Pi. Well, you can build the image on any architecture, but you can’t run an ARM compatible image on the Mac (or docker-machine/boot2docker).

Ok, so that in mind, there are a number of ARM compatible images on Docker Hub already – Hypriot also have base images ready to go. So to run Spring Boot in a container on the Pi, I need an ARM image with Java. Luckily, here’s one ready to go.

For a quick test, I took my simple Sprig Boot REST app I already have on GitHub, and threw together a Dockerfile using Alpine first to check it would run locally:

FROM java:openjdk-8-alpine

ADD SpringBootREST-0.0.1-SNAPSHOT.jar /opt/SpringBootREST-0.0.1-SNAPSHOT.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/opt/SpringBootREST-0.0.1-SNAPSHOT.jar"]

This runs as expected in docker-machine on my Mac.

To push to the Pi, the only change is to replace the base image with an ARM compatible image with Java, so this looks like:

FROM hypriot/rpi-java

ADD SpringBootREST-0.0.1-SNAPSHOT.jar /opt/SpringBootREST-0.0.1-SNAPSHOT.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/opt/SpringBootREST-0.0.1-SNAPSHOT.jar"]

To get it to my Pi, I set up a local Registry to push the image to, and then pulled it from the Pi. So tag the image to the registry:

docker tag spring-boot-rest-rpi registry-ip:5000/spring-boot-rest-rpi

…push to the registry:

docker push registry-ip:5000/spring-boot-rest-rpi

and then pull from the Pi:

docker pull registry-ip:5000/spring-boot-rest-rpi

And then fire it up!

docker run -it -p 8080:8080 registry-ip:5000/spring-boot-rest-rpi

Spring Boot in a Docker Container on the Pi!

Posted on

Raspbian USB disconnects and USB keyboards

I was looking for a solution to a USB soundcard that would randomly disconnect from my Raspberry Pi (it’s a Signalink USB soundcard/radio interface for amateur radio). Turns out, the issue I was seeing was caused by RF getting into somewhere when my radio was keying up – when I moved the HT radio further away from the Pi (only as far as the length of the connecting cable, a few feet) then my problems stopped. This could probably be avoided better with some snap-on ferrite beads.

In this post (and others), there is a suggestion about adding dwc_otg.speed=1 to your /boot/cmdline.txt. I tried this for a while and this didn’t seem to make any difference to my USB disconnects for this particular USB soundcard. It did however stop a USB keyboard from being recognized (a Gear Head Mini USB). Remembering I had added this param and then removing it solved my keyboard issue.

Lesson learnt: if trying out solutions to problems by trial and error, if something doesn’t work, remember to remove it afterwards in case it breaks other stuff 🙂

 

Posted on

Tuning Direwolf packet parameters for use with HT radios

Direwolf has a  number of tuneable properties – by default after installing and configuring the basics, your callsign etc, it normally ‘just works’. I’ve been experimenting setting up Direwolf and PiLinBPQ as a BBS on a Raspberry Pi, and using axcall or LinPac on another Pi with Direwolf to call into the BBS. I have a Rigblaster and Yaesu FT60 HT on one Pi, and a SignaLink and Wouxun HT on the other radio.

The problem I ran into was that either Pi seems to work ok to call into a Packet node nearby, but calling from one Pi to the other was pretty unreliable in terms of not decoding packets, and the number of retries before a packet would get received and decoded. I tried a number of options, and feedback in the Yahoo Groups Direwolf group give me some suggestions to try. The tuning parameters are all covered in the excellent Direwolf docs.

Possible problems with using HTs for packet could include a combination of these factors:

  • Receive audio too loud into Direwolf (aim for around 50)
  • Receive audio not loud enough – adjust soundcard volume (Rigblaster/Signalink) and alsamixer levels
  • The radio doesn’t transition quick enough between transmit and receive (can be fixed by adding DWAIT)
  • Latency from the soundcard audio either in receive or transmit – can be fixed by adding TXDELAY for delay at the start of the transmission, and/or TXTAIL for a delay at the end

The settings I finally wound up with on both Pis that worked for me are:

DWAIT 20

TXDELAY 60

TXTAIL 60

 

 

 

Proudly powered by WordPress