This is an old revision of the document!
Work in progress!
Make sure to cover the chip of the display with something light tight (permanent marker, dark nail polish etc.). (This is not an actual light sensor, but open silicon which in the normal use of the display would be covered by a case. Not adding the paint should not damage the display but you won't enjoy it)
Come to the muCCC village and use the flash station to reflash your badge.
If that didn't fix it, try switching the badge off. Before switching it on again, push the joystick to the right (away from DARC) and then switch on the badge.
Another issue might simply be an empty battery, so have a try with recharging.
If you soldered in the SMA connector, you might have shorted the left ground pad to a VCC pad underneath. These two pads which are separated only by a small margin must not be connected.
me@you:~$ hackrf_info hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000) me@you:~$ modprobe -r hackrf me@you:~$ hackrf_info Found HackRF board. xxxxxxxxx....
If you are running Arch Linux there might be a similar problem but of different origin. The solution is provided within the hackrf-github Issue page.
Make sure that USB autosuspend is disabled, as the first contact with rad1o after resuming fails, and default autosuspend delay in Linux is pretty short (2 seconds).
Currently, the only known solution is to do a reflash of the rad1o.
You could give following a try:
- find the mounted partition of you rad1o, check therefor the output of mount (see following example)
/dev/sdb on /media/you/FE49-AB84
- unmount the partition
- run fsck on that partition
fschk.vfat -v /dev/sdb
- follow the instructions of fsck
- to prevent this happen again, eject the partition properly
either: umount /dev/sdb or: use the eject functionality of your desktop manager
sudo hackrf_infoworks but plain
hackrf_infodoesn't, see I can't use HackRF without sudo below, or run
If you run HKRF-OLD (not HACKRF), the device registers as idProduct 6089, and you will probably not have this problem. If you're sure that you want to use HACKRF, idProduct is cc15, and both udev and gnuradio have to know about this ID.
udev: move 53-hackrf.rules to /etc/udev/rules.d and do
Make sure you did not turn on the generation of documentation, or install `doxygen` through your package manager.
1d50:cc15⇒ probably not recognized by older HackRF software)
1d50:6089⇒ recognized by older HackRF software)
The LEDs section is answering all regular questions that came up.
During camp we try to regularly get firmware updates here, keep in mind that it will not always be up to date with the f1rmware repo:
Usually no parts need resoldering but we occasionally notice that the following three parts are sometimes not soldered perfectly:
If you experience an error that may relate to any of these three, we recommend a close look at the solder pads of those parts. WARNING: Always unplug the battery when soldering, especially when soldering the battery connector!
Please have in mind that rad1o's internal antenna is tuned for about 2.4 GHz. This means that it cannot perform eg. in the FM Band (87.5 to 108 MHz). Sorry - but that's physics. If you need good performance, consider adding an SMA connector and an antenna that is optimized for the specific frequency.
When you build an unmodified of a l0dable and try to run it from the campapp you could get an error like:
To fix this, try rebuilding the campapp and replacing camp.b1n
Reason: usb-autosuspend. manually configured auto-suspend or you may have laptop-mode-tools or tlp (thinkpad powersaving tool)
Solution: disable usb-autosuspend for ids 1d50:cc15 and 1d50:6089 (if your using tlp add USB_BLACKLIST=“1d50:cc15 1d50:6089” to /etc/default/tlp)
Your battery is empty.
perhaps you soldert together the two tiny smd resistors next to the lower right WS2812b led. In my case that disables the switch. When i removed the tin it works again.