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.
My second NinoTNC is built. The parts came today from Mouser in a huge box. I need to adjust the case a little to make it fit nicely but now I have this one I can go mobile and see how access to GB7RVB is. So far, no-one has connected (and yes, the antenna is still in the loft!)
I did find a TNC program for the Mac called KISSet which works fine once I remembered to put my callsign in! I wondered why it was sending data and GB7RVB’s TNC was receiving – no callsign. Twit. It worked fine after that.
I have a Tait TM8110 VHF transceiver that is destined for use on packet radio. This was sold as untested but appears to work fine. However, in testing I was concerned that the bench PSU I connected it to showed a current draw of 0A. The radio was making noise and, connected to the Bird and a dummy load was generating RF. Anyway, I programmed it with the various packet frequencies, power settings and ensured the bandwidth was 12.5kHz and tried it on air. It was working fine on both tx and rx. But still 0A draw. Hmmm.
I have two identical bench supplies, Lavolta BPS-305, 30V 5A units. One has a noisy fan so I use the other. I swapped to the noisy one and it shows reasonable current draws for rx and tx. And then the noisy fan decided not be noisy any more (still working though!) so perhaps the noise from this PSU was just it sulking from being ignored.
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.
Tidying up the whole shack make life easier to reach stuff but did not completely cure one issue, that of RF flying about the place and getting into things where it was not wanted.
I tried 10m this morning and two things happened. First, it set off the house alarm. Second, wsjt-x would not hold a tx cycle or tuning. The autotune was happy but that acts quickly. Using wsjt-x’s tuning for a few seconds, or transmitting a CQ and the FT450D would tx, then off, then try again etc. This has happened before.
First off, yes there is RF in the shack and it’s due to the rather naff antenna wire in the loft. I need to live with that until I get some wire in the air outside. And yes, I’ve been saying that for ages! But before it was really down to the mass of cables all entwined and those have been completely tidied up now. So I was rather annoyed that the same issue has returned.
And then I discovered that my attempts to dust round the desk had moved the serial cable between the FT450D and the Signalink and it was now laid across the antenna cable. Moving it cured the issue. For some reason when I fitted ferrites to that cable I only put one at the Signalink end, not the rig end. Fixed that too.
Some leads are still too long though. No sense really in tidying the place up but leaving long leads, so some soldering is planned…
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!
Still sorting the shack out today, hopefully two more days and it’s done. Today’s task was to fit PoE HATs to the two Raspberry Pi systems that run things like Pi-Star, the ADSB grabber and HamClock. These were both Pi 3B’s which do not have the pins for PoE – the 3B+ or the 4 does.
So, first off, strip the cards out of the box. Not too bad. The first Pi 4 and its HAT was easy but the Pi Star one has the RF board. Installing the PoE HAT does not leave any of the Pi 4’s pins protruding. Fortunately I had a small stock of extenders, in fact, just enough. Not the neatest of constructions but it works.
One thing caught me out though. The Pi Star Pi gets a static IP address via DHCP. When it booted up it would not let me connect or get to the web interface. A scan of the network found it and only then did I remember that, of course changing the card means a new MAC address! Anyway, both cards now have their MAC addresses in pi-hole (even though the IP is static doing it that way makes pi-hole record their activity against the names) and the Pi Star one has been reconfigured with a static IP rather than DHCP.