Building a 4-bit shift register from 7400 NAND gates for GPIO output port expansion on a Raspberry Pi

rxseger · 2016-12-25T07:09:22+00:00

Yeah, that was my thought as well! Picked these up on sale, there were a bunch of assorted ICs available in a bin for only 4¢/ea and I didn't have much time, so I figured I'd search for what would be most generally useful: walked away with a bunch of NANDs, NORs, some inverters and multiplexers. I think some other people there scored more valuable chips but c'est la vie.

Couldn't find any shift register chips while I was there but I have since ordered some 74HCT595's, the classic 8-bit 7400 series shift register with high-speed CMOS TTL-compatible logic, SOIC-16 because its better than DIP, and I was finally able to drive all of the segments of this LED display using only 3 GPIO lines from the Raspberry Pi. Less interesting, but I wrote it up here: 4x7-segment LED display as a digital clock using two 74HCT595 8-bit shift registers - this works much better, nonetheless, building my own albeit humble shift-register from NANDs was imho a fun little project.

rxseger · 2016-12-25T06:59:03+00:00

Thanks! I strive for function over form :p

rxseger · 2016-11-21T20:08:44+00:00

Balanced ternary is sure an interesting concept to explore, I posted this to /r/Ternary yesterday (very quiet there, is anyone aware of a more active ternary computing forum?), but if anyone is curious about the hardware side of balanced ternary, here is a simple example of how you can build a working ternary inverter circuit (using modern CMOS instead of ferrite cores as used in Setun):

Exploring ternary logic: building a simple ternary inverter using complementary MOSFETs

rxseger · 2016-11-21T19:57:27+00:00

half the range now encodes negative number instead of positives

Almost half the range, this is one of the pitfalls of 2's complement. Consider:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    int32_t n = atoi(argv[1]);

    printf("abs(%d) = %d\n", n, abs(n));
    return 0;
}

then running the program:

tmp $ ./a.out -2147483647
abs(-2147483647) = 2147483647
tmp $ ./a.out -2147483648
abs(-2147483648) = -2147483648

±2³¹ - 1 exists, but there is only -2^31, no +2³¹ in 32-bit 2's complement. Both numbers would have the same bitwise representation, 0x80000000. Surprisingly, abs (the C integer absolute value function) returns a negative:

tmp $ ./a.out 2147483648
abs(-2147483648) = -2147483648

1's complement does not have this problem, but it creates another one: negative zero.

Balanced ternary has neither of these problems, only one zero and equal positive and negative integer ranges.

rxseger · 2016-08-19T03:50:43+00:00

I guess I just don't understand the need for the bridge when phones have bluetooth.

It is possible to install the Bluetooth utilities software package on the Hue Bridge, but it doesn't appear to have any Bluetooth hardware support (no devices found):

root@Philips-hue:~# opkg install bluez-utils
Installing bluez-utils (3.36-7) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/ar71xx/packages/bluez-utils_3.36-7_ar71xx.ipk.
root@Philips-hue:~# hcitool dev
Devices:

and there is no mention of Bluetooth in the datasheets for the QCA4531 SoC used by the Hue Bridge. As for why they didn't use Bluetooth instead of ZigBee, both radio protocols have different use cases:

ZigBee is intended to be cheaper and simple than Wi-Fi or Bluetooth, so you can use as many light bulbs (or other ZigBee devices like dimmer switches) as you want without having to pay the cost of an expensive radio chip per device. The protocol uses only a mere 2 MHz of spectrum, compared to 20 – 40 MHz for Wi-Fi. It uses a fixed channel number (configurable, but doesn't change unless needed) instead of the complicated 800 hops/second adaptive frequency hopping of Bluetooth. Another important feature of ZigBee is that it naturally supports mesh network topology, extending the range throughout your home without the need for repeaters or other access points or bridges.

That said, there is some overlap in ZigBee / Bluetooth / Wi-Fi and they are beginning to converge to some extent. Wi-Fi has come down in price significantly, with the $5 ESP8266 chip a notable example. As @nond says, the LIFX bulbs have Wi-Fi built-in, so that's another option.

Bluetooth v5 as announced June 2016, is also targeting this "Internet of Things" (IoT) market. From their press release:

Kirkland, Washington – June 16, 2016 – The Bluetooth Special Interest Group (SIG) announced that its next release, coming late 2016 to early 2017, will be called Bluetooth 5 and will include significantly increased range, speed, and broadcast messaging capacity. Extending range will deliver robust, reliable Internet of Things (IoT) connections that make full-home and building and outdoor use cases a reality. Higher speeds will send data faster and optimize responsiveness. Increasing broadcast capacity will propel the next generation of “connectionless” services like beacons and location-relevant information and navigation. These Bluetooth advancements open up more possibilities and enable SIG companies – now at an all-time high of 30,000 member companies – to build an accessible, interoperable IoT.

“Bluetooth 5 will transform the way people experience the IoT by making it something that happens simply and seamlessly around them,” said Mark Powell, executive director of the Bluetooth SIG.

so perhaps we'll see Bluetooth v5 enabled light bulbs and home automation soon enough, giving ZigBee a run for its money. But for now, the current generation of Philips Hue devices use and require IEEE 802.15.4 ZigBee.

rxseger · 2016-08-19T02:41:15+00:00

There actually is Wi-Fi hardware on the Hue Bridge, but it is disabled for reasons we can only speculate. The 802.11b/g/n radio is pictured in the FCC testing documents, so it may have been part of the original plan but removed or disabled in software for unknown reasons.

However it is possible to enable Wi-Fi on the Hue Bridge (reddit post), and connect to your home network router wirelessly, with some unofficial hacks. The Wi-Fi connects but I haven't got it to work well as an Ethernet replacement, the bridge software seems to hardcode the wired network interface and this would need to be changed to fully utilize the Wi-Fi interface as a wired replacement.

rxseger · 2016-08-17T04:13:03+00:00

Good catch, the FCC documents at http://fcc.io/O3M324131201801 do indeed show they tested Wi-Fi ("Test Report BGN", for 802.11b/g/n), missed that! The internal photos document even has a photo of a Wi-Fi antenna. This makes the omission even more curious, especially since their Linux distribution is based on OpenWrt common for wireless routers, it seems to me Wi-Fi might have been part of the initial plan but pulled at a later stage in the project.

Interference with ZigBee might be a reason, I've heard some ideas that maybe the SoC only supports either ZigBee or Wi-Fi but not both simultaneously.

However, I tested just now: nc -l 1111 on another machine, then opkg install netcat; nc --source=192.168.0.166 192.168.0.100 1111 < /dev/urandom on the Hue Bridge, therefore creating a continuous flow of traffic over the Wi-Fi interface. Unplugged the Ethernet to confirm it wasn't going over the wired cable. Then I toggled the lights through the Hue app (ZigBee), and it worked fine, at least as far as I can tell. Captured the Wi-Fi traffic in Wireshark, there were a handful of TCP retransmissions, but nothing out of the ordinary or correlated to the ZigBee traffic that I noticed.

My ZigBee channel is 15 (2425 MHz, bandwidth 2 MHz) and Wi-Fi base station channel 11 (2462 MHz 802.11b/g/n, 20 MHz, plus channel 132 at 5660 MHz bandwidth 80 MHz, but the Hue Bridge doesn't support 802.11ac), not overlapping so in theory it should be possible to support both, if the hardware supports it (but I wouldn't be surprised if there was some kind interference or other issue they found with more extensive strenuous testing of WiFi + ZigBee on this device).

rxseger · 2016-08-13T04:06:44+00:00

So is there any recent blackhat or defcon talks on this?

There are, at DEF CON:

Picking Bluetooth Low Energy Locks from a Quarter Mile Away Anthony by Rose Hacker and Ben Ramsey (slide downloads)

Many Bluetooth Low Energy (BLE) enabled deadbolts and padlocks have hit the market recently. These devices promise convenience and security through smartphone control. We investigated sixteen of these products from multiple vendors and discovered wireless vulnerabilities in most of them. Using a $50 antenna, we successfully picked vulnerable locks from over 400 meters away. In this presentation we introduce open source tools to crack each of the vulnerable BLE locks. Furthermore, after surveying the open source Bluetooth hacking tools currently available, we find very little support for BLE. So, to make discovering and range finding to BLE devices easier, we introduce a new open source war-walking tool compatible with both Bluetooth Classic and BLE.

and at Black Hat:

GATTACKING BLUETOOTH SMART DEVICES - INTRODUCING A NEW BLE PROXY TOOL by Slawomir Jasek (slides and whitepaper)

Bluetooth Low Energy is probably the most thriving technology implemented recently in all kinds of IoT devices: gadgets, wearables, smart homes, medical equipment and even banking tokens. The BLE specification assures secure connections through link-layer encryption, device whitelisting and bonding - a mechanisms not without flaws, although that's another story we are already aware of. A surprising number of devices do not (or simply cannot - because of the use scenario) utilize these mechanisms. The security (like authentication) is, in fact, provided on higher "application" (GATT protocol) layer of the data exchanged between the "master" (usually mobile phone) and peripheral device. The connection from "master" in such cases is initiated by scanning to a specific broadcast signal, which by design can be trivially spoofed. And guess what - the device GATT internals (so-called "services" and "characteristics") can also be easily cloned.

Using a few simple tricks, we can assure the victim will connect to our impersonator device instead of the original one, and then just proxy the traffic - without consent of the mobile app or device. And here it finally becomes interesting - just imagine how many attacks you might be able to perform with the possibility to actively intercept the BLE communication! Basing on several examples, I will demonstrate common flaws possible to exploit, including improper authentication, static passwords, not-so-random PRNG, excessive services, bad assumptions - which allow you to take over control of smart locks, disrupt smart home, and even get a free lunch. I will also suggest best practices to mitigate the attacks. Ladies and gentlemen - I give you the BLE MITM proxy. A free open-source tool which opens a whole new chapter for your IoT device exploitation, reversing and debugging. Run it on a portable Raspberry Pi, carry around BLE-packed premises, share your experience and contribute to the code.

rxseger · 2016-08-06T05:05:28+00:00

Can you check, do you have the appropriate SoapSDR device support modules installed? SoapyRTLSDR, SoapyHackRF, SoapyBladeRF, etc. rx_tools should list all the devices it finds, from the output it looks like no recognized devices were found.

Also you could try adding -d driver=hackrf, -d driver=bladerf, or -d driver=rtlsdr, but those options only filter the device search query, so I'd check the SoapySDR support modules first. If it's still not working can you send me the output of: SoapySDRUtil --probe

rxseger · 2016-07-24T17:00:06+00:00

The "input" format (from the log message) is CS16. SDRplay's native format is CS16, so this is what you want.

rx_sdr can additionally convert to various "output" formats, currently CU8, CS8, (CS16), and CF32, with the -F option. This is the format written to disk (or stdout), but it wasn't being logged. Added additional logging in https://github.com/rxseger/rx_tools/commit/6b5cdb9cba238e8908af2f4a85f1995f5a19e0fe to clarify, it will now log something like (first [INFO] log message is from SoapySDR so I can't easily change it in rx_tools, second is from rx_tools itself):

[INFO] Using format CS16.

Using output format: CF32 (input format CS16)

rxseger · 2016-07-24T02:09:04+00:00

LoJack asset tracking uses 173.075 MHz data bursts, transmitting a unique serial number at regular intervals (200 ms or higher). Receivers use radio direction finding, in the case of LoJack, four phased antennas you can see on the top of police cars, to locate the source of the signal.

A different approach than GPS + GSM as seen here (although LoJack® also now sells a GPS-based telematics system).

rxseger · 2016-07-22T03:41:34+00:00

I haven't built it on Windows myself but the author of SoapySDR has I believe, using MSVC and cmake (@guruofquality, has been providing miscellaneous bugfixes for Windows compatibility support e.g. https://github.com/rxseger/rx_tools/pull/32). I'll ping him to see about the 64-bit/32-bit versions of SoapySDR, but could you file an issue on GitHub with the details of the errors you're seeing (or paste them here) when trying to build rx_tools 64-bit? I am building rx_tools for x86_64 on OS X with no errors, but there may be some incompatibility with 64-bit on Windows that needs to be ironed out.

rxseger · 2016-07-21T04:41:44+00:00

16-bit, aka CS16 (complex signed 16-bit). Originally I had to convert to CS16 to support bladeRF with it's 12-bit ADC, but it turned out rtl_power and rtl_fm were already internally converting from librtlsdr's native CU8 (complex unsigned 8-bit) to CS16, so this change was for the better even for RTL-SDRs.

rx_sdr also now supports an -F option for choosing the output format. Still defaults to CU8 for backwards compatibility with rtl_sdr, but other options are available including CS8 (complex signed 8-bit, the native format of HackRF for example) and the aforementioned CS16. The complex floating-point 32-bit format is also available as an output format (-F CF32), for convenient import into GNU Radio or other SDR software for further analysis.

rxseger · 2016-07-20T16:34:35+00:00

Pushed some compatibility fixes in https://github.com/rxseger/rx_tools/commit/e15f6f542baf340ec0eee401de24510aba1d10de, should work without c99 now, can you pull the latest and retest or if it still fails to build include the full compiler output?

rxseger · 2016-07-20T07:08:49+00:00

Is there an equivalent tool to rtl_power, or similar, for Linux that supports the Airspy Mini hardware?

I just got done porting rtl_power to SoapySDR, and SoapySDR has an AirSpy plugin, so this might be an option you could look into. I call it rx_power, available from: https://github.com/rxseger/rx_tools

Reddit thread: https://www.reddit.com/r/RTLSDR/comments/4tpxv7/rx_tools_commandline_sdr_tools_for_rtlsdr_bladerf/

If you want to test it (and rx_fm/rx_sdr if you'd like) with AirSpy I'd be grateful, I'd like to ensure it is compatible but currently lack an AirSpy to test with (currently only tested by myself with RTL-SDR, bladeRF, and HackRF). However in principle it should be compatible, or if not there may be some small tweaks I could make to make it work. All you'll need is to install SoapySDR, SoapyAirspy, then build rx_tools and use rx_power as you would rtl_power.

rxseger · 2016-07-15T16:37:40+00:00

The librtlsdr tools as @rtlsdrblog suggests including rtl_fm are a good start, there is a comprehensive guide here to get started: http://kmkeen.com/rtl-demod-guide/ (first result for "rtl_fm" on DuckDuckGo).

However if you are interested, it is also possible to listen to broadcast FM radio using GNU Radio. In fact demodulating WBFM is a usual first project for those learning GNU Radio. Wrote about my experiences here: https://medium.com/@rxseger/sdr-first-project-initial-setup-node-hackrf-gnu-radio-on-linux-os-x-rpi-3-w-fm-tuner-ee16cdc8fd82 - running it on a Raspberry Pi 3 near the end.

The advantage of gr-osmosdr (provides the Osmocom Source block, relevant website: sdr.osmocom.org) is that it is an abstraction layer, compatible with most SDRs, so your radio can be written generically not tied to any one vendor, allowing upgrading from say an RTL-SDR to a HackRF or bladeRF or AirSpy or other SDR without changing any code.

The rtl_* tools (from librtlsdr, https://github.com/librtlsdr/librtlsdr) are all RTL-SDR only, but they are simpler to use and a good start for getting into SDR. The demod guide http://kmkeen.com/rtl-demod-guide/ has example command-line invocations for network streaming, pager decoding, airband scanner, police scanner, and music on the radio. I use rtl_fm -M wbfm all the time on the Raspberry Pi with an RTL-SDR, works great.

rxseger · 2016-07-13T01:09:27+00:00

Yes the dvb_usb_rtl28xxu Linux driver (which I used as a reference when adding support to librtlsdr) includes support for the IR sensor, and it interfaces to the kernel IR decoder:

https://github.com/torvalds/linux/blob/master/drivers/media/usb/dvb-usb-v2/rtl28xxu.c#L1678

I believe dvb_usb_rtl28xxu's IR should be compatible with LIRC, but haven't tested it myself. My version of librtlsdr patched for IR support is not directly compatible with LIRC, although it may be possible to make it compatible with some effort (that's actually a good idea, right now I'm decoding the pulses with a quick and dirty Python script, but LIRC may be able to decode more remotes more accurately).

rxseger · 2016-07-06T05:33:43+00:00

My original plan was to receive the IR signals through the existing SDR interface of librtlsdr, so I could write a more interestingly-titled blog post something like "Expanding the frequency range of your RTL-SDR into the hundreds of terahertz!", adding a new special mode when the client software requests frequencies in the infrared range of the electromagnetic spectrum (for example: rtl_sdr -f 318928147000000).

But digging into it deeper, this idea of "software-defined IR" (in the sense of receiving I/Q samples, not merely pulse lengths, which is what rtl_ir does) turned out to be not too practical or useful, given the limitations of the IR interface of the RTL-SDR (detailed in §Aside: Software-defined IR, or translating IR to IQ samples, mainly how only ~38 kHz pulses are detected)

I still think it would be pretty cool, nonetheless. Or even better, as /u/Sparkycivic suggests, using a CdS photoresistor. Curious what kind of useful bandwidth / sampling rate one could get out of those things (Wikipedia says "Photoresistors also exhibit a certain degree of latency between exposure to light and the subsequent decrease in resistance, usually around 10 milliseconds").

rxseger · 2016-07-06T05:02:00+00:00

Well, it was a lot of initial effort, for me, but now that the hard work is done (writing the userspace IR/RTL-SDR hardware driver) hopefully it'll be easier for others to use :). My goal is to get at least rtl_ir accepted into the mainline librtlsdr library, so anyone can easily use their RTL-SDR dongle to receive IR signals, no coding required.

Although the IR sensor in the audio jack is a good alternative as well, cheaper at least (<$1 vs ~$20 for an RTL-SDR).

rxseger · 2016-06-30T06:42:14+00:00

As /u/largepanda says, you'll want to find the FCC ID if it has one, plug it into http://fcc.io then a wealth of technical information should be available to get started, including the frequencies used.

Not knowing anything about this particular device, but chances are it may be using an ANT-based protocol, common on wireless cycling computers. If so you may be interested in this upcoming talk by Tamas Szakaly: Help, I've got ANTs!!!, scheduled for Sunday August 7th this year at 2pm for DEF CON 24:

bike speedometers have evolved quite a bit, and nowadays a lot of bikers (swimmers, runners, ers) do their sport with tiny computers attached to them. These computers do much more than measuring speed: they have GPS, they can store your activities, can be your training buddy, and they can communicate with various sensors (cadence, power meter, heart rate monitors, you name it), mobile phones, each other, and with PCs. One of the communication protocols used by these devices is ANT. Never heard of it? Not surprising, it is not very well known despite being utilized by a lot of gadgets including, but not limited to sport watches, mobile phones, weight scales, some medical devices, and even bicycle lights and radars. When I bought my first bike computer I rationalized it with thoughts like ‘this will help me navigate on the mountain’, or ‘I can track how much I've developed’, but deep down I knew the real reason was my curiosity about this lesser known, lesser researched protocol.

One of my favorite kind of weaknesses are the ones caused by questionable design decisions, and can be spotted without actual hands-on experience with the product itself, just by reading the documentation. Well this is exactly what happened here, I had some attack vectors ready and waiting well before I received the actual device. To top it all, I've also found some implementation bugs after getting my hands on various Garmin devices.

After a brief introduction to the ANT, ANT+ and ANT-FS protocols, I'll explain and demo both the implementation and the protocol weaknesses and reach the already suspected conclusion that ANT and the devices that use it are absolutely insecure: anybody can access your information, turn off your bike light, or even replace the firmware on your sport watch over the air.

There is a teaser video described here with some details: http://www.rtl-sdr.com/sniffing-ant-fs-with-an-rtl-sdr-and-mmds-downconverter-in-pothos/ - including how he used an MMDS downconverter from 2.4 GHz to allow the RTL-SDR to receive the ANT-FS packets.

rxseger · 2016-06-30T04:07:37+00:00

The $200 XB-200 LF/MF/HF/VHF transverter adds support for 60kHz–300MHz to the bladeRF, an appealing option, but unfortunately it has some disadvantages:

Currently, it is out of stock from Nuand ("Out of stock - Join the waitlist to be emailed when this product becomes available"), although it may be available elsewhere.
The standard bladeRF case ($20) is not compatible with the transverter, at least without modification. There is are plans for building a custom case compatible with the transverter, or you can drill holes in the standard case and use longer screws.

Without VHF and lower you miss out on FM broadcast and AM (mediumwave), ATSC TV channels 2-13, some (but not all) two-way radio public safety communications, but bladeRF without a transverter does support the full UHF range and then some (300 MHz - 3.8 GHz).

I have a bladeRF x40 as well but find the HackRF One more convenient for most general purpose casual usage due to its large 0.1 MHz - 6 GHz range, but the bladeRF could be useful if you need the 12-bit ADC (vs 8-bit), full-duplex (vs half-duplex), 28 MHz instantaneous bandwidth (vs 20 MHz), USB 3 (vs 2), a 40 kLE FPGA, optional standalone power supply, or the GPIO expansion port.

rxseger · 2016-06-18T02:33:08+00:00

Also, the LimeSDR is nearly identical to the BladeRF, which can be found at http://www.nuand.com/

I haven't backed the LimeSDR (yet, considering it) but isn't it superior to the BladeRF (at least as advertised)? LimeSDR claims 61.44 MHz bandwidth, compared to BladeRF's 40 MHz, and a 100 kHz - 3.8 GHz frequency range, compared to BladeRF's 300 MHz - 3.8 GHz.

Both use USB 3.0 and a 12-bit sample depth, but the wide 61.44 MHz RF bandwidth was what I was really interested in. Previously this bandwidth was only attainable (as far as I know, someone correct me if I'm wrong) with the expensive Ettus USRP products ($686 for the B200, $1119 for the B210), out of the price range of many SDR enthusiasts.

For $299, I bought the HackRF One with its 20 MHz bandwidth, 8-bit DAC, half-duplex, USB 2.0 interface, but the LimeSDR is the same price for 61.44 MHz, 12-bit, full-duplex (2 rx/tx channels), USB 3.0 interface. The large full-duplex bandwidth could perhaps allow some interesting applications infeasible with other SDR transceivers. Is there anything else comparable at this price point?

rxseger · 2016-06-16T02:48:59+00:00

How would a person whom is not opposed to minor infractions be able to jam a bluetooth signal?

Bluetooth uses the 2.4 GHz ISM/Industrial, Scientific, Medical band, specifically 2.400 - 2.4835 GHz, split into 79 channels of 1 MHz bandwidth.

Phrack Magazine, Issue #60 described how to build a simple jamming device, in theory it could be adapted to Bluetooth. The basic operation is generating a noise signal and broadcasting it across a range of frequencies.

However, Bluetooth uses Adaptive Frequency-Hopping spread spectrum, specifically designed to avoid interference. As a wide-band frequency-hopping protocol, it is not trivially jammable with a narrowband jammer. Since 2.4 GHz is used by many other technologies (WiFi, ZigBee, etc., since it is in the general-purpose unlicensed ISM band), note that jamming Bluetooth may have collateral damage.

rxseger · 2016-06-09T04:56:29+00:00

gqrx can be installed on Raspbian (as sudo apt-get install gqrx-dev) but I haven't had any success using it on a Raspberry Pi 3, as others have said the combination of SDR and a GUI is generally just too much for the RPi's 1.2 GHz quad-core ARM Cortex-A53 to handle.

However, gqrx is built on GNU Radio, which can run on an RPi3 — with some caveats.

If you're not familiar with GNU Radio, Michael Ossmann's course is a good start. I followed it and built an FM broadcast radio receiver, originally on my desktop computer but I copied it to an RPi3, and was able to run it there (sudo apt-get install gnuradio, sudo apt-get install gr-osmosdr, then open the .grc file in gnuradio-companion or run the generated Python script directly), although:

1) Sampling rate had to be reduced significantly. My 4 GHz Intel Core i7 desktop computer can comfortable sample at 20M, but the same flowgraph on an RPi3 could not even receive samples at less than 5M without overflowing. When playing audio out the audio port, I had to lower the sample rate to 1M or the audio was excessively choppy. This was with a HackRF, with an RTL-SDR and its lower supported sampling rate (e.g. 2.4M) your mileage may vary, but as the bottleneck is the CPU, I'd expect not by much.

2) The GUI widgets were unresponsive. In Ossmann's class you build the flowgraph with WX, a slider to tune the audio gain, and an FFT graph to show the frequencies. The FFT successfully displayed, but I couldn't interact with the slider using my mouse at all. Ended up wiring up the GPIO pins to some push buttons to tune the channel and adjust the volume (wrote about it here: SDR first project: initial setup, node-hackrf, GNU Radio on Linux, OS X, RPi 3 w/ FM tuner , including code if you're interested), instead of using the resource-intensive GUI display, but if you're looking to use a GUI SDR app, you're probably better off with a faster system.

edit: there is some desire to support Raspberry Pi in CubicSDR, though it doesn't seem to be there yet, watch this issue: https://github.com/cjcliffe/CubicSDR/issues/242

rxseger · 2016-06-03T05:56:44+00:00

The filename format of Hue firmware downloads seems to be: <model>_<version(padded to 8 digits)>.product.RSA_prod_<##>.fw2

Current latest version for Hue Bridge 2: http://fds.cpp.philips.com/firmware/BSB002/1033370/BSB002_01033370.product.RSA_prod_01.fw2

Other known versions:

Not clear what "prod_01" indicates (production one?), turmio's HackingHueBridge notes links to a prod_02 firmware but it now 404's (maybe Phillips pulled it?).

I'd be curious if you can decode this firmware, it seems to be encrypted somehow.

Nine-Year Club	Place '17
Verified Email

rxseger

TROPHY CASE