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 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!
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.
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…
See, I built it! And it works. The 3D printed case needs a bit of tidying but is perfectly functional. All I need now is a radio to use it with plus probably re-use one of my spare Pi 3B cards to drive it.
Note to self… stop collecting bits for projects and start building instead!
Just in, this PCB and chip for the TARPN NinoTNC. Described as a multi-speed, multi-protocol USB-KISS packet radio interface this comes as a very nicely made PCB and PIC plus a bill of parts complete with Mouser part numbers and a spreadsheet that loads into Mouser to make a complete order.
Recently the outside lights here decided to switch off at random intervals for no apparent reason. There are 5 different controllers, two being Zigbee bulbs and the others Zigbee switches. All use 2.4GHz. All had been running reliably for maybe a year. On/off cycles are controlled by scripts on the server as well as manually via an app.
In each case whichever set of lights had gone out did report as being off and would turn back on via the app. Some days there was no issue, on others at least one would go off at some point. The Zigbee bulbs never failed, just the switches.
There was no evidence of any commands being sent to turn the lights off, but there was the occasional error being reported. Rebooting the server made no difference. A power cycle of the server seems to have cured the issue so I am considering it likely to be the Zigbee transceiver itself.
This is now nagging at me to figure out what happened and presumably it will reoccur some time in the future. Too many other things to sort out though!
It’s surprising just how many things one gathers that need Ethernet. Having just made an NTP server out of a Raspberry Pi that took the last port in my 8+2 port PoE switch I needed more ports. The switch is a Netgear GS110TP, 8 Ethernet ports and up to two SFP modules for interlinking.
So I have added a second GS110TP linked to the original one via a short fibre lead and two SFP transceivers. The house now has 4 Ethernet switches, all Netgear, making 48 Ethernet ports in total but not all in use, plus 3 wifi access points, Netgear again and all PoE powered.
Actually I could have settled for a non-PoE switch as the additional one but this one came cheap, and new in box.
All the switches and access points do SNMP too, centrally monitored using MRTG. Why? Because they can!
I decided to make my own Stratum 1 NTP server for the home. No, I don’t need the accuracy, but localising stuff like that is always interesting. So, I recently purchased an Uputronics GPS HAT from Pi Hut which is marked Raspberry Pi GPS+RTC Rev 6.4. It arrived next day along with some other bits. I also got another PoE HAT and already had a Pi 4. Raspbian installed on an SD card – this time I remembered to first set it up to work via ssh – and the Pi booted ok with the GPS board flashing it’s ‘time pulse’ LED once per second.
I followed instructions on the web, in particular from the two websites shown at the bottom of this post. Initial setting up of the Pi involves the use of raspi-config to stop the serial port login shell but leaving the port enabled, and disabling serial getty and bluetooth. At this point, doing cat /dev/ttyAMA0 should return data from the GPS receiver but all I got was garbled characters. More on that later.
The next step was to enable PPS support which involves modifications to /boot/config.txt and a module adding to /etc/modules, plus downloading pps-tools. Running sudo ppstest /dev/pps0 looked ok but again, more on that later.
Next was to install gpsd and modifying /etc/default/gpsd plus setting it up to run at boot time. After a reboot running sudo service gpsd status returned valid information.
The gpsd-clients package was installed which includes gpsmon. Running gpsmon showed that all was not well. It generated a few lines but nothing that meant any sense.
I then returned to sudo ppstest /dev/pps0 and noticed this time that all it was giving was timeouts. I may well have missed this in my haste earlier as it reports ok, but then gives timeouts. An, unfortunately not recorded web page suggested adding arm_64bit=0 to /boot/config.txt and after rebooting sudo ppstest /dev/pps0 now produced a valid line, once per second. Ok.
Retracing my steps I ran gpsmon again to take a closer look and noticed that in the few lines it managed to display was the entry ‘”bps”:9600’.
That was the lightbulb moment.
The GPS board defaults to 115200. Stopping gpsd and running minicom -b 115200 -o -D /dev/ttyAMA0 produced valid GPS data. Modifying /etc/default/gpsd to set the baud rate to 115200 (GPSD_OPTIONS=“-n -s 115200”) fixed the issue.
But, gpsmon still does not produce all the output that I had expected, in particular it does not populate the time and date fields. Running cgps does show valid information and suggests that all is well and there is something I am missing regarding gpsmon. At the end of the day it all appears to be working fine.
The next package installed was chrony. This all went to plan and running chronyc and its sources and sourcestats options showed valid data after the system had settled down for a couple of minutes after boot.
The final leg of this journey was to set up various systems to use the new NTP server. On the Pi systems this is typically done via /etc/systemd/timesyncd.conf and then restarting systemd-timesyncd; the Mac was done via System settings –> General –> Date & Time, and the various network switches and wi-fi APs each had their own way but each was obvious. Of course one thing to remember is these are all static systems that never leave the house. Setting a local IP into a mobile system would not be that great an idea.
The final thing that tripped me up was that in chronyc options such as clients would give an error. Running chronyc under sudo fixed those.
And there it is in a tall metal Pi case also from Pi Hut and rather unceremoniously chopped with some cutters to enable the SMA connector to fit. This case has plenty of vertical space for the Pi, the PoE HAT and the GPS HAT.
