Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.

--

When I wrote the article back in May, I hardly thought that LoTW would be down a month later.

Sadly, the outage continues. 

My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.

Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.

I do hope it is soon. I'm really missing this service.

This article describes a Arduino based thermometer using a 1-wire DS18B20 digital temperature sensor using a SDD1306 or SH1106 OLED display.

The DS18B20 is a digital sensor, used for relative noise immunity, especially given the choice of an OLED display.

This is a basis for tinkering, for modification and a vehicle for learning.

Above is the sample display.

The code is written to support multiple sensors on the 1-wire bus, it cycles through each of the sensors displaying them for 1s each.

Parasitic power

The DS18B20 can be connected using a two wire connection and using “parasitic power”.

Above is a simple scheme for parasitic power which should work with one master and one sensor at the other end of the cable for tens of metres. For longer cables and multiple sensors, see (Maxim 2014).

Note that the Vdd pin is tied to ground.

1-Wire

Above is a capture of the DQ line for search and read of a single DS18B20.

Above is a zoomed in view of the 1-wire encoding format.

I2C display

The display uses I2C.

It takes just under 25ms to paint the display using the example code.

Source code

Here is source code that compiles in the Arduino IDE v2.3.2.

#define VERSION "0.02"
#include 
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 32 // OLED display height, in pixels
#define TEMPMIN -20
#define BARGRAPH
#define PPD 2 //pixels per degree, must be +ve integer
#define TICKMIN 5
#define TICKMAJ 10
#define SSD1306_DISPLAY
//#define SH1106G_DISPLAY
#if defined(SSD1306_DISPLAY)
#define OLED_RESET    -1 // Reset pin # (or -1 if sharing Arduino reset pin)
#include 
Adafruit_SSD1306 display=Adafruit_SSD1306(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
#endif
#if defined(SH1106G_DISPLAY)
#include 
#define WHITE SH110X_WHITE
#define BLACK SH110X_BLACK
Adafruit_SH1106G display=Adafruit_SH1106G(SCREEN_WIDTH,SCREEN_HEIGHT,&Wire);
#endif
#include 
DS18B20 ds(2);

#if defined(__AVR_ATmega328P__)
HardwareSerial &MySerial=Serial;
#endif

int i;
int barh=SCREEN_HEIGHT/2-2;
int basey=display.height()-1;
int tickh=barh/4;

void setup(){
  float adcref;
  long adcfs;

  #if defined(__AVR_ATmega328P__)
  analogReference(INTERNAL);
  adcref=1.10;
  adcfs=1024;
  #endif
  analogRead(A2); //Read ADC2
  delay (500); // Allow ADC to settle
  float vbat=analogRead(A2); //Read ADC again
  vbat=16*(vbat + 0.5)/(float)adcfs*adcref; //Calculate battery voltage scaled by 150k & 10k
  // Display startup screen
  MySerial.begin(9600);
  MySerial.println(F("Starting..."));
  #if defined(SSD1306_DISPLAY)
  display.begin(SSD1306_SWITCHCAPVCC, 0x3C);  //Initialize with the I2C address 0x3C.
  #endif
  #if defined(SH1106G_DISPLAY)
  display.begin(0x3C, true); // Address 0x3C default
  #endif
  display.setTextColor(WHITE);
  display.clearDisplay();
  display.setTextSize(1);
  display.setCursor(0, 0);
  display.print("DS18B20 thermometer");
  display.setCursor(0, 12);
  display.print("ardds18b20 ver: ");
  display.println(VERSION);
  display.print("vbat: ");
  display.println(vbat,1);
  display.display();
  delay(1000);
}

void loop(){
  int i,j;
  float temp;
  uint8_t id[8];
  char buf[27];

  j=1;
  while (ds.selectNext()){
    //for each sensor
    ds.getAddress(id);
    sprintf(buf," %02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X ",id[0],id[1],id[2],id[3],id[4],id[5],id[6],id[7]);
    temp=(ds.getTempC());
    MySerial.print(j);
    MySerial.print(buf);
    MySerial.print(temp,2);
    MySerial.println(F(" °"));
    display.clearDisplay();
    display.setCursor (0,0);
    display.setTextSize(2);
    display.print(j);
    display.print(F(": "));
    display.print(temp,1);
    display.print((char)247);
    
    #if defined(BARGRAPH)
    int w=(temp-TEMPMIN)*PPD;
    //draw bar starting from left of screen:
    display.fillRect(0,display.height()-1-barh,w,barh,WHITE);
    display.fillRect(w+1,display.height()-barh-1,display.width()-w,barh,BLACK);
    //draw tick marks
    for(int i=0;i<SCREEN_WIDTH;i=i+PPD*TICKMIN) display.fillRect(i,basey-barh+3*tickh,1,barh-3*tickh,i>w?WHITE:BLACK);
    for(int i=0;i<SCREEN_WIDTH;i=i+PPD*TICKMAJ) display.fillRect(i,basey-barh+2*tickh,1,barh-2*tickh,i>w?WHITE:BLACK);
    if(TEMPMIN<0) display.fillRect((0-TEMPMIN)*PPD,basey-barh+tickh,1,barh-tickh,i>w?WHITE:BLACK);
    #endif

    display.display();
    j++;
    delay(1000);
    }
  delay(100);
  }

This code suits a 128*32 pixel display. Changes will be needed to optimise other display resolution.

Github repository

See https://github.com/owenduffy/ardds18b20 for code updates.

See https://github.com/owenduffy/tds18b20 for a platformio implementation.

References

Maxim. 2014. Guidelines for long 1-wire networks.

May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.

That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error. 

So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.

Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.

But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information. 

Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.

What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.

I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.

“Zilog has called time on the Z80 CPU.” (https://www.theregister.com/2024/04/29/opinion_z80/) Wow. Actually I had no idea (through never having checked) that it was still being produced.

And a fine chip it was too. I never built a system from wires up using the Z80 though. My first system, designed, built from chips and wire-wrap was an 8080 system, hand programmed to control al x-ray diffractometer. This was decades ago now but I still remember it, although I have no photos unfortunately. The system had a timer chip for a 1-second count and was interface to a Nuclear Engineering (I think it was!) counter that used nixies.

But I did at least use Z80s, just they came as boards. The first was a Transom Triton computer and by then I was programming in Turbo pascal – back then this was really neat as one could have procedures full of assembler code which made interfacing easy. Later I used Gemini boards and that also gave the ability to have a graphics card. By then my interfacing to the diffractometer included a stepper motor and shaft encoder to control the arc motor.

In the end there were two sets of Gemini Z80 boards, one for the x-ray diffractometer and one for an optical microdensitometer. Both gathered data and were interfaced to a mainframe computer for the processing using a suite of Algol 60 programs. Good old days…

Personally my first system was a 6502 Newbear single board, followed by the ubiquitous Nascom 1 which was, of course, Z80 based.

Farewell, Z80…

I now have a Raspberry Pi set up on one of the four monitors in the shack. The original layout was two screens at the top on Linux, then bottom left on Windows and bottom right – central to where I sit on the Mac as the main screen. But that layout had two major issues…

I use a program called Barrier to basically act as a KVM switch for the three systems with the Mac as server. That way the Mac mouse and keyboard controls any of the systems, although it can be awkward sometimes where Windows expects keys which Apple doesn’t have. But Barrier does not understand dual monitors and so moving the mouse up from the Mac got to the Linux box fine, but moving it down from the left hand screen would not get to Windows as the program does not see it being physically there. I could live with that, except for issue two…

The main issue was with the Linux screens being at the top and thus making me sit back or crank my neck upwards, not a good position.

So…

I got to realising that although I use both screens on the Linux box for radio stuff this tends to be with wsjt-x on the right screen and pskreporter on the left.

The solution, which somehow never occurred to me, was simple. Move all the wiring about so that the Mac is right and central, Linux is to the left at eye level so no neck ache, Windows is top right because I rarely use it anyway, and that left a dead screen top left. Enter a Pi 4B. So now I can arrange the four screens with pskreporter top right, Hamclock top left, wsjt-x bottom left and logging bottom right. QED.

Some time ago I wanted a logging program that would do things my way. Although there is absolutely nothing wrong with any of the various offerings they generally try to be everything for everyone and none of them really sat well with me. So I wrote my own in PHP (learning Python is high on my list of things to do, along with Mandarin, Morse, cooking…) which uses the QRZ.com logbook as the backend. Ok then, really I wrote a series of various scripts in PHP that make it all work. The advantage is it does just what I need and nothing more and can easily be modified to add functionality. The downside is I never was a coder (well, ok, I have a certification in COBOL from the 1970’s!) and it is not going anywhere other than my own server. So you can’t have it…

The way I tend to log stuff is via wsjt-x or other software that logs to a local file. I then have a script that takes the ADIF data and populates QRZ.com on a QSO-by-QSO basis. Somehow having to actually do something after each QSO feels like I am actually engaging in the process. But I am not a contester… it would simply not work for any stress situations (but then I could easily make it work if I so desired…)

With QRZ.com being the master a script then populates a local database which does all manner of stuff that I personally need. For example, it holds records of eQSL sent/received, real QSL sent/received, and various tabular data for Worked All Britain (WAB).

Scripts also modify the wsjt-x log file on all my systems such that each has a record of all QSOs. As QRZ.com is globally accessible (not tried from China mind… not that I plan to take any radio gear there anyway) and my main database is on a VPS so is also globally accessible the various scripts work from anywhere.

I do plan to move the database from the VPS to a system at home once we get FTTP broadband and use the VPS as a backup, synchronising between the two. But that will wait.

One plan which is more immediate is LoTW integration because as yet my LoTW logging is via QRZ.com which means an extra step. No biggie, I mean it’s its a few clicks and a password… but it would be nice to integrate it. The same goes for eQSL sends, but as yet I only send on receipt and I have scripts to deal with that anyway.

I’ve been rationalising hardware, in particular as the PoE HAT on the Pi running the GB7RVB packet mailbox was noticeably noisy and needs replacing. I had originally moved the packet mailbox off of my AMPRnet router Pi as I needed to install a VPN and the networking was becoming a bit too complex for my liking. In the end I had no use for the VPN, so GB7RVB has gone back, removing one Pi.

Linbpq went across just fine – there is an apt for it (https://wiki.oarc.uk/packet:linbpq-apt-installation) so installation is easy. Just install and copy the config across and the files under /opt/oarc/bpq (there are neater ways but this sledgehammer method works). With the node running I could access via the web interface as expected, but then the axudp route disappeared.

Then I realised that our broadband router had a NAT rule for the UDP port needed for axudp and that was still pushing it to the now switched off Pi. And I’m sure I’ve forgotten this same thing before! So now I have a note as a reminder, assuming I bother to check the note…

Now having removed one Pi with a noisy fan the NTP server Pi is also whining. Grumble.

In 1984, I was working at Hayes Microcomputer Products. They were the premiere modem manufacturer for small computers, back in the days when modems over telephone lines were a primary means of computer to computer and user to computer communications. 

In my job, I created communications software to talk to the modems. The software dialed the modem, established connection, provided terminal emulation (my specialty), allowed for the capture of the data stream to files, printing, file transfer with the remote computer (using protocols like XMODEM and YMODEM), and other features. 

These were the early days of personal computing. IBM introduced the PC in 1981, and it had rapidly evolved into a defacto standard computer, shoving out various CP/M designs from the previous decade. Personal computers were so new, people were trying to figure out what to do with them. Word processing, spreadsheets and other office applications had just been introduced. 

Hayes was trying to stay at the forefront. We had a laboratory filled with pretty much one of every personal computer, and when new ones came out, we would buy one. In late 1983, we got an Apple Lisa. It was a very different kind of computing experience. It was a curiosity to us, and as there was no programming environment available, we didn't see how we could build software to talk to a modem. Plus, at the price point, there were few buyers.

The Macintosh

The Machine

Next Steps

We were soon green lighted to create a product for the Macintosh.

256 KB Gimix Static RAM board, sans battery.

In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a  2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s. 

By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment. 

Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler. 

Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive. 

In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte. 

I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.

All this packet radio progressing around the place reminds me of a time long ago, pre-Internet where dial-up BBSs became the new thing in town. Back then I had a BBC Micro and a modem that ran at two speeds – I forget which now (will edit later!) and I persuaded my mum to get BT in to fit a socket rather than the hard-wired phone we had then. This let me plug the modem in. I used to use a BBS called ‘More Summer Wine’ plus one other but I forgot the name. Much of the activity back then is lost in the mist of time (or rather I just can’t remember) but sending and receiving mail was fun. BBS systems were all a part of the wider FidoNet. Mail would be routed between the various BBS systems, many of which only had the one telephone line and so would be inaccessible while that was happening. Indeed, they were mostly single user anyway, although if the sysop was there you could message them via the console of the BBS which was probably sitting in someone’s bedroom. I am reminded of the many times I would set the BBC and modem up on the hall floor because we only had the one telephone socket. In fact, it would be quite some time between then and when we finally got broadband Internet which for us was not until the later 1990s in our new home.

During that time and working in academia I had routine access to networks and mail and so interest in the BBS systems dwindled. There was a time before the winder Internet became available where we could gain network access to remote systems, all typically mini- or mainframe computers. One such system ran a MUD – Multi-user Dungeons and Dragons – another angle to remote access but this time for gaming rather than BBS. That provided an introduction to online chatrooms because the MUD we used to play on had that feature. One could not only progress through the game but also exchange messages online, the latter becoming the wanted feature vice the game itself.

And here we are. I was never involved in packet radio when it first came to be, but now it has reminded me a lot of those old days of the dial-up BBS.

And FidoNet? It is still there https://www.fidonet.org/

See: https://spectrum.ieee.org/social-medias-dialup-ancestor-the-bulletin-board-system

WD2797 controller card for 5 1/4" drives

To work on OS-9, I borrowed some 5 1/4" drives, and used the SWTPc DC-2 controller. This allowed me to boot up OS-9. Single-sided, single-density, 40-track diskettes hold about 100 KB -- they were quite limited on space.

Back side of 5 1/4" controller

Drives

5 1/4" Drive Cabinet

Finding a cabinet to house three drives was a problem. New metal cabinets are very expensive, particularly in larger sizes, and I couldn't find anything suitable on the surplus market. 

Inside the box, plenty of room.

Future

Well. Further to my previous post where all hope seemed to have gone out of the window I finally made progress today, but not the way I set out to.

First off, I pulled a Raspberry Pi 4 from another project and sat the CaribouLite HAT on it.

Next was a fresh installation of DragonOS. But this time it did open the ssh port – I’ve no idea why it did not before and note I am being unscientific here as I changed the Pi, but I am not going backwards.

Then, time for install.sh…

All seemed to go well but the software failed to compile completely. Searching on the errors I added #include <memory> to two source files, cariboulite/software/libcariboulite/src/CaribouLiteCpp.cpp and cariboulite/software/libcariboulite/src/CaribouLite.hpp. Stripping out all the ‘apt’s and ‘depmod’ from install.sh and running it again and the software compilation completed! I had already added and commented out the necessary lines in /boot/firmware/config.txt so a reboot was all that was needed to kick it into life. The driver was loaded – lsmod|smi showed this and also /proc/device-tree/hat now exists, both precursors to success according to the notes and YouTube videos.

Running sudo SoapySDRUtils –find showed the card, and, finally (!), running SoapySDRServer –bind and CubicSDR on the Mac mini finds the server on the Pi and I can tune to the local radio station.

Success, but that was a struggle. Mind you, I learned stuff at least!

I came across this via a post someone made somewhere – actually it might have been an email on a group. Anyway, with a tx/rx range top to 6GHz I thought, why not? It arrived quite quickly from Crowd Supply via Mouser with Crowd Supply charging the VAT but no other taxes on arrival.

I duly mounted it on a spare Raspberry Pi 3B with a fresh Bookworm 64 bit OS and followed the installation instructions at https://github.com/cariboulabs/cariboulite but I always got various errors and never got to a working system. The errors were mainly surrounding the SMI driver and the kernel headers. There seemed no way round this one, and thus no working system.

Following on from another complaint I downloaded and installed DragonOS, a 64 bit variant with lots of SDR utilities built in. Once installed, although the developer stated that ssh is available from first boot and does not need the usual empty ssh file it is not – the system does not open port 22 but does open the vnc port so I then had to find out which of my desktop systems has a vnc viewer as I never use it. When I found one and connected all it gave me was a blank screen. But guess what? Adding an empty ssh file onto the SD card worked, despite the advice!

Following the guidance from one user regarding getting the cariboulite to even install I did a complete upgrade / dist-upgrade cycle and then began the installation process. This time there were no errors about SMI or the kernel headers but there were fatal errors in the general build and no working system at the end.

After countless iterations, reading comments from other users, watching YouTube videos etc. I had to admit defeat and give up.

So there we are. On one hand it serves me right for not finding and reading all the issues before ordering this thing, but on the other given it costs money I rightly expect more, i.e. something that actually works rather than something that will sit in a box until maybe, one day the developer sorts the mess out. As it is I would compare it to the excellent SDRConnect and RSP SDR products which just work – this is the exact opposite!

In a nutshell, don’t bother with this card. But then, you never know, maybe the developer will sort the software and I will re-visit this post in a more positive light.

Update: there is a fork of the software detailed at https://github.com/cariboulabs/cariboulite/discussions/82 but following those instructions in a fresh Bookworm throws up the same kernel header errors and results in no SMI driver. So no go there. I tried the same in a fresh DragonOS – I must have been mistaken about the ned for the ssh file because I added this but DragonOS never opens the ssh port for me. So, no go there either!

All in all this has been a lesson in how to waste many hours for no gain. YMMV. There are a few other web pages with differing views and builds which I may try but as a product this is really, really poorly supported by the developer.

I learned about OS-9 in early 1983, when it was new. What I heard mainly concerned BASIC09 and at that time BASIC didn't interest me. That was unfortunate. OS-9 is a miniature Unix clone, optimized for the 6809.

Baud rate generator and counter/timer board

Requirements

Interrupt Logic

ROMs

I thought I was going mad today. I wanted to print some rails for the FT817 and I already had the sliced files on the SD card in the 3D printer. I selected the first (there are two, one is a mirror of the other) and told it to print. Nothing. Reset the printer and tried again. Nothing. Opening the SD card on the Mac showed the file to be 0 bytes, which is certainly was not as I had printed it before. Ok, copy it again and try again. Nothing!

Right. Delete all the files on the SD card – I have them all on the Mac anyway. Copy just the files for the rails across and try again.

Nothing!

Looking at the SD card via a terminal window – I must admit to be my favourite UI – it was full of all sorts of junk. Going duff perhaps? Ok, use a recycled 8Gb micro-SD in a holder, delete all the files currently on it, copy the rails across and try that. Ah, the files did not delete so it’s full of old junk and I can’t spot the files to print. Back to the Mac. Tried 3 times with different holders to delete all the files on this micro-SD and each time unmounting and re-mounting it showed they were all still there. That micro-SD is in the bin now.

Right! Use another micro-SD, delete all the old files, copy just the two gcode files across and …. it’s printing!

Wow.

Here is the setup for GB7RVB, not much to see really. The radio is a Tait TM8110 which has been configured according to information on the OARC wiki. The NinoTNC is next to it, both currently sitting on top of my Portsdown. Above, and annoyingly not square because I need to move some cables, is the Pi 4 which is PoE powered from a Netgear switch.

I actually achieved something. Makes a change!

At this stage I must state that I overlooked the fact I have an FTM100 and it has a suitable interface! Ok, no way I am going to fiddle soldering a 10-pin mini-DIN plug even if I had one, so I ordered a CT167 cable from www.JGTech.com  which arrived within two days. I already had a stock of D9 plugs. With the NinoTNC connected to the Windows PC the APRSIS32 software could send and receive APRS to/from my FT2D (no APRS activity round here other than a receive-only igate).

But packet was a tad more problematic. I wanted to use the Windows PC + Signalink + FT817 setup which means using QtSoundModem on the PC, but I also needed a program to talk to the TNC. QtTermTCP will via KISS but neither the Mac or Linux version had KISS anywhere to be seen, only AGW. And any mix of QtSoundModem and QtTermTCP on the Windows PC generally resulted in nothing talking to anything, which is probably my fault but it definitely got in the way.

So… I set up an old Pi 3B with the LinBPQ software, connected the NinoTNC / FMT100 to that and set up a test configuration. I then ran up QtSoundModem on the Windows PC talking to the FT817, and QtTermTCP on the Mac talking to the Windows QtSoundModem via AGW. And… nothing! The node sent broadcasts which were picked up by QtSoundModem etc. but connects to it all failed.

I noticed that if I sent APRS from the FT2D the OK LED on the TNC would light, but if I sent anything via QtSoundModem only the DCD flashed, no OK. Data issues then. It was then that I realised that in my earlier fiddling about with QtSoundModem I had all the various options in weird modes. Turning off FX25 and IL2P in the modem setting cured it (and no, I have no idea why I had them switched on!), and I could then connect. Success.

So, packet radio across the shack, using two radios, three computers and a NinoTNC.

Next steps… in theory anyway… I have a Tait TM8110 on order via eBay and a cable on order, I already have the programming lead and software. If all goes to plan I may even be able to build a packet node and get a NoV for it. As there is nothing at all round here then this may be a start if I can get others interested. I am to far away from other nodes in the progressive national packet network, but, early days…