Refreshing a JAX-RS backend with some Node.js and Express?

Over the past few year or so, I’ve been building a web app that visualizes amateur radio spots using a digital mode called JT65. The site is currently up and live here: http://www.spotviz.info/#/home

I started building this as an exercise to learn some AngularJS 1.x (I posted a number of posts along the way too). The backend datastore is MongoDB, and there’s a JAX-RS War deployed to WildFly that provides a REST backend to the AngularJS frontend. The majority of the logic for the webapp is all in the AngularJS app.

Since playing with some Node.JS and Express a couple of weeks ago, I’ve been considering if I should have a go at replacing the JAX-RS code with a Node.js backend too. Since the existing code is mainly building and executing MongoDB queries, this wouldn’t be that hard to do a straight replace. Based on what I’ve seen so far of libraries like Mongoose, the replacement code is likely to be significantly more concise than the existing Java based backend. I’ll queue this up for a project in the coming weeks 🙂

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 🙂

 

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

 

 

 

Resolving SSH laggy responsiveness over Wifi on Raspberry Pi / Raspbian

It’s interesting to note that turning off the power saving features for the common Wifi dongle chipsets used on Raspbian seems to fix not only the pauses where before it would sleep during inactivity, but also it seems to fix/improve the laggy responsiveness even when typing commands over SSH to a Pi. Links to the settings in my previous post here.