Testing out the IoT pHAT

Hail, people!
Continuing on from last time, I had a little time to muck about with the IoT pHAT to try to get a general idea of how well it worked. What I did was to test out WiFi only, BT only, then WiFi + BT. I’ve described them as Tests 1, 2 and 3 respectively below. These tests were carried out on a Raspberry Pi Model B+ running the 2016-11-25 version of the Raspbian Jessie Lite distribution.

Test 1
For the WiFi only test, I placed the pHAT on a B+ and edited the /etc/wpa_supplicant/wpa_supplicant.conf file to (auto)connect to my home WiFi network. Did a reboot, and voila, the ‘raspberrypi’ entry showed up in the router’s DHCP table. I was able to login via SSH and transfer a few files using WinSCP. Overally it performed flawlessly here – the connection was rock solid and performed satisfactorily. I didn’t run any iperf tests though – this is because I don’t intend to use the pHAT for any applications where throughput is an issue anyway. But I don’t expect it to be (significantly) slower than a regular USB WiFi adapter.
Test 2
Next up was the Bluetooth test. A friend had recently setup his Pi for Bluetooth audio streaming, so I thought it’d be a nice idea to give it a shot as well. I followed the steps from this link and got it working. To make it a truly BT-only test, I shut down the WiFi interface by running sudo ifdown wlan0. Note that you need to execute the “pulseaudio –D” command on every boot to actually be able to stream audio to the Pi. You should probably do it on startup by adding a boot script but this was for testing purposes so I didn’t bother. Hooking up an old pair of PC speakers, I was able to stream audio with no issues/glitching whatsoever.

Test 3
For the final test (the one you’ve all been waiting for Winking smile Winking smile ) I hooked the Pi up to a keyboard and screen, then rebooted. When it came back up, the WiFi adapter came back up as expected. I ran the pulseaudio –D command to permit audio streaming. Next, I connected to the Pi and began to stream audio. The WiFi apparently had a significant impact on the Bluetooth link quality – I had plenty of glitches at fairly regular intervals. The WiFi connectivity on the other hand didn’t really seem to be affected. I closed the audio stream and disconnected from the Pi’s Bluetooth device, then disabled WiFi (sudo ifdown wlan0). Restarting the stream, it returned to being smooth (as in Test 2). We can therefore summarize that WiFi + BT on the IoT pHAT is not such a great idea if you’re doing high throughput comms. Audio streaming certainly qualifies as a high throughput application, so this is not particularly surprising. Its possible that a firmware update might fix this though. That said, if you’re doing something undemanding I suspect the impact of WiFi would be far less acute. That’s something else to test though.
For the price of the IoT pHAT though, I got a rock-solid WiFi connection (which was what I really wanted anyway) with a good range. Bluetooth also works but seems to suffer when simultaneously using WiFi, which is kinda understandable really. The pHAT may get updated firmware at some point which may further mitigate these issues. But it is truly plug and play and works with no issue (at least for my purposes, thus far).
My mystery hardware has arrived, so I should be talking about that soon.
Auf Wiedersehen!

Comments

Post a Comment

Popular posts from this blog

Getting Started with Logic Analyzers and Pulseview

Image
Hey all, Been a while. Hope you’ve been up to no good, hm? A couple of days ago, I had to do some low-level I2C work on a bare-metal ATMega328P. Digging out the datasheet, I cobbled a simple I2C driver together, the purpose of which was to permit me write a driver for the particular peripheral which would call the lower-level functions the driver provided (i.e things like i2c_start(), i2c_stop(), i2c_address(), etc etc). When I finished the I2C driver, I tested it out with an MMA8452Q I had lying about and it seemed to work just fine. Believing everything to be dandy, I went ahead and wrote the peripheral driver for the component I was working with. And that was when the funny stuff started. To cut that long story short, it wouldn’t work right when deployed to the hardware. At all. I was in a bit of a bind – the code looked great, no errors no nothing, so it was time to look at the hardware/wire-level end of things. Logic analyzers (in my limited understanding) are tools/instrume...
Read more

Bitbanging SPI on the Raspberry Pi (via spi-gpio)

Image
Hello all and happy holidays to everyone! I’m taking a break off work for the holidays so I have a little bit of time on my hands. I will therefore regale you with tales of my exploits! From my last post, I talked about the somewhat “edge” case where you’d want to add (cheap) Ethernet to a Raspberry Pi, probably the A+ or Zero as the case may be. I haven’t figured out the fixed MAC thing just yet, but I’m working on it. Anyways, after some time, another edge-edge case came to me: The ENC28J60 takes up the only SPI peripheral available on the Pi, so what if you needed to use both the ENC28J60 AND some other SPI device? The Pi’s SPI peripheral has two chip selects, so it is theoretically possible to use the exact same bus while using the first chip select for the ENC28J60 (which it uses by default) and using the second chip select for the other device. However, it goes without saying that network communications require some serious computing firepower so it might cause a bit of a perfo...
Read more

Enabling SPI1 on the Raspberry Pi B+/Zero/2/3

Image
Me hearties, Let us plunder and pil.. Sorry, wrong blog. Ahem. Hey all, Its been a while. Been busy at work as usual, and haven’t really had much time to write much. As penance, I will post not one but two updates! This particular post is in relation to Raspberry Pi users specifically. I had earlier talked about the vagaries involved in emulating SPI over GPIO in order to get an additional SPI peripheral. It was a moderately involved process, but the rewards were great With the most recent release of the Raspbian Jessie distribution (2016-05-10), a number of improvements have been made to both the desktop parts and the “under-the-hood” parts, perhaps most significantly the kernel. This new release uses Kernel version 4.4, which now adds the ability to use the second hardware SPI peripheral, SPI1, on the Raspberry Pi. This is only available to devices with the 40-pin header (as seen from the title of this post) so users of the original model A and B will probably need to turn to...
Read more