Review: Raspberry Pi 3 – More Pi, No Cables Attached?

It’s been a while since I checked out the Raspberry Pi, as my fleet of original Raspberry Pi Model B, B+ and Pi 2 Model B’s have all been working well doing their little jobs around the house. I haven’t really felt an inclination to upgrade, despite the original Pi feeling a little dated and underpowered, as for single-purpose jobs, they are more than enough.

However, rather surprisingly, the Raspberry Pi Foundation never seems to stop and incremental upgrades come rather quickly. In February this year, they launched the third iteration of the Raspberry Pi – namely the Raspberry Pi 3 Model B. This unit replaces the Raspberry Pi 2 Model B, and offers a faster 1.2Ghz 64-bit quad-core ARMv8 CPU and built-in 802.11n 2.4Ghz Wireless LAN and Bluetooth 4.1 + Low Energy capabilities while retaining the same footprint, I/O and RAM for a very similar price (AU$55 excluding GST at the time of writing). Getting more Pi for your dollar is a nice thing, especially when it remains software-compatible, and the inclusion of wireless eliminates one common USB-port-hog and means it’s very much ready for easy IoT deployment out of the box.

Thanks to element14, I have finally managed to get my hands on a Raspberry Pi 3 Model B to gawk at, put it through its paces and play around with.



As with other element14-supplied Raspberry Pis, this one comes in a matte colour print cardboard box. Along its spine, it is familiarly raspberry-coloured with the logo and brand.

2016111814249429 2016111814249432

2016111814249430The design changes subtly for each model, and in the case of the Pi 3, it looks rather plain with a more “muted” raspberry. The front has logos for Wireless LAN and Bluetooth, and the rear has the appropriate regulatory approval logos including the Australian regulatory compliance mark (RCM). Getting such approvals for wireless radios can be a rather expensive and long process, so having this integrated would have probably been a big step for the Raspberry Pi Foundation to accomplish. That being said, I’m not sure if this has the full Wi-Fi Alliance “blessing” as it doesn’t carry that logo, although I’m sure most people wouldn’t really care as long as it interoperated just fine as that might just add to the cost. This particular unit is Made in China, which seems to be along the lines of the recent Pis and a little disappointing for the UK perhaps.


Inside, the main PCB is wrapped inside a static shielding bag, with a folded safety guide and quick start guide leaflet. Just as with the other Raspberry Pi models, the rest of the components are an “optional BYO”.


The board retains the familiar footprint and I/O layout which was standardized in the Raspberry Pi Model B+ era. This means size compatibility with cases, as the jacks are all where you’d expect them to be. A few things have changed though:

  • Placement of the power and activity LEDs is now near the bottom left corner, meaning the holes and or light-pipes used in Raspberry Pi B+/Raspberry Pi 2 B-era cases will now instead be facing the Wi-Fi/Bluetooth on-board chip antenna. This is a minor inconvenience, as it just means the status lights may not be visible from the outside without drilling a hole. In the case of the official Raspberry Pi case, the red LED is visible through the plastic, but the green LED is not. Clear cases don’t have to worry.
  • The run/reset header has been moved from near the top left to the top-mid-right just behind the USB connectors. This is likely because that area is now dedicated to RF-componentry.
  • On this board, the HDMI, USB and FFC connectors have been changed to different units – I can’t say whether there is any meaningful difference, as it should be functionally identical.
  • The Raspberry Logo has moved from near the DSI connector to above the CPU, and gotten marginally smaller. The board now carries an FCC ID, as it has a radio on board.
  • The SoC is now a Broadcom BCM2837, a faster 1.2Ghz 64-bit quad-core ARMv8 CPU as opposed to the BCM2836 900Mhz 32-bit quad-core ARM Cortex-A7 CPU used in the Raspberry Pi 2 or the BCM2835 700Mhz 32-bit single-core ARM11 CPU used in the original Raspberry Pi series.


On the underside, there are a few differences as well:

  • For one, there seems to be a lot more test points scattered around the place, with some pads tinned and others not tinned.
  • There is a new bare silicon-chip mounted onto the board which is likely to be the radio IC. Purportedly, it has FM radio capabilities which are not allowed for in the Raspberry Pi design.
  • The board manufacturer has changed from KCE to JX.
  • The microSD card slot has been changed from a “push-push” type with springy eject to a friction fit slot. This might have been a necessary cost-reduction measure to make everything “fit” into the budget. It’s not likely to make a big difference to most users.


The power comes from a microUSB-B connector as before, although in the case of the Pi 3, they claim a maximum power draw of 2.5A rather than the 1.8A claimed in the Pi 2. This is a little confusing to me, as most microUSB-B connectors are only specified for 1.8A, so maybe it’s just pushing the limits ever so slightly as a way of noting the increased power draw of the SoC while allowing for equivalent downstream USB peripheral loads.

2016111814279437 20161118142894392016111814279438

From the other sides, not much as really changed, save for the positioning of the LEDs and chip antenna in this model. The chip antenna seems to be made of a metallized spiral deposited on some sort of dielectric core.


A side by side comparison with the Pi 2 shows the many similarities and few differences.


It’s been a long time since I’ve had to set-up a Raspberry Pi from scratch, so I headed over to the Raspberry Pi Foundation’s site to grab the latest Raspbian Jessie (Lite and Full) images. It’s also good to note that some of the OSes made for the Raspberry Pi 2 have been updated for the Raspberry Pi 3, so really it’s only the original Raspberry Pi that misses out on Ubuntu Mate, Windows 10 IoT Core, etc.

So many nice things have happened since I last used it – for one, it seems the image auto-expands to the size of your SD card on first boot. As usual, SSH is open from the beginning so a headless install is simple and only needs for you to ssh to the user account pi with password raspberry on the IP it has been assigned. The reminder to run sudo raspi-config is no longer there, but the tool still works and gives a few new options.

For one, you can now enable a VNC server without all the fuss of setting your own x11vnc server up from scratch or dealing with Krfb quirks.

raspi-config-vncYou can also set the Wi-Fi region setting for compliance with local laws, specific for the Pi 3. Of note is that overclocking the Pi 3 through raspi-config is not supported and comes up with this message.

pi3-no-ocMore options in regards to how it boots up, including waiting for network, auto-login, console-or-desktop really makes things easy to set up. Some things are still best done through manual editing of the /boot/config.txt. For example, I set a fixed framebuffer size of 1920×1080, since I would be exploring the graphical desktop via VNC instead.


Because the included VNC server came from RealVNC, and the UNIX password authentication method and encryption was not supported by my other clients, I had to use RealVNC to connect the first time.

rvnc-v2After first setting up the connection in the main window, and then attempting to connect, I’m prompted to verify the identity. Because I didn’t know the specific signature, but I trusted the network I was on, I proceeded.

rvnc-v3Login with the username and password combination that has been set on the Pi and we’re off and running. As simple as that!

vnc-dialogI was quite impressed, however, by double-clicking on the icon, we can configure the server to improve its compatibility with other clients (at the cost of security – the loss of encryption and UNIX user login support).

realvnc-server-windowTo do this, we need to click on More …, followed by Options.


Configure the Authentication from UNIX password to VNC password, then navigate to Users & Permissions and set the VNC password.


Optionally, you can also configure the other tabs to stop serving the Java/HTTP VNC viewer (connect with port 5800, no software needed). Whatever you do, don’t enable the direct capture method as it will result in screen geometry issues. I did it, and I had to use a physical USB Keyboard and Mouse to recover.

wifi-scan-netThe main attraction of on-board Wi-Fi worked just a treat. Clicking on the network icon allowed us to view the nearby Wi-Fi networks. The signal strength appears slightly lower, due to the chip antenna being less optimal. Clicking on a network and providing the necessary authentication key allowed me onto my home network without any hassle at all.


wifi-connectedThe connection obtained was probably more solid than that achieved by using the Wi-Pi, and it doesn’t hog any of the USB ports or use any USB bus bandwidth as far as I can tell. The fact it is integrated is a big boon for IoT users as it means that it can get to the internet without any wires or hassle, so pushing sensor data to the cloud is no big problem at all. I can even run remote VNC desktop which is somewhat bandwidth heavy with no real issues either. Big tick of approval!

bt-add-deviceThe fun doesn’t stop there, because the radio also has Bluetooth 4.0 with Low Energy support. This means that those using BT-LE sensors for data can use the Raspberry Pi 3 as an IoT gateway, extending the reach of their Bluetooth devices.

bt-add-device-2Consequently, if you’re feeling like a little challenge, you could even use the Bluetooth link to talk to speakers/headsets for an audio output. This is normally a difficult task as support can be somewhat flakey, but as I demonstrate with connecting to my Xiaomi mini speaker, it worked a treat! bt-paired-okbt-select-audio-outTo activate it, it’s as simple as right-clicking on the speaker icon and choosing the Bluetooth device as the audio output device. bt-audio-works

The default browser is now Chromium, so none of the old Epiphany “scaled back” browser stuff of the old days, and the performance is better than expected. It’s no desktop replacement, but it’s not a test of patience as it once was. I was able to play Rainy Mood over the Bluetooth speakers (with an occasional resampling crackle), so that was unexpectedly smooth!


CPU usage was also quite low, showing there’s a lot more ability up the sleeve of the Pi 3. Youtube was a bit of a stretch though, and the Bluetooth audio driver seems to crash-out to silence when overloaded necessitating a reboot to restore its functionality.

However, most of the time, the Bluetooth is most useful for attaching keyboards and mice wirelessly (e.g. home media center usage) or reading sensor data, connecting to Bluetooth serial devices or performing small file transfers, which really makes this Pi work in many places with “just power” connected.

Hot & Thirsty Pi: A Stability Problem?

The Raspberry Pi 3 has developed a bit of a reputation of being “a bit hot” and needing a little more power. However, in return, you get more peripherals and more performance. I wanted to see just how much more you get, so I tried to use it a little more heavily and run some benchmarks.

The honeymoon was indeed sweet but shortlived, as after some rather intensive usage, I found that the Pi would hang and sometimes never come back after a power cycle. The microSD card would be trashed, and I would have to reimage it. A closer look showed that the power LED would flicker, indicating a short power brown-out despite being run on numerous 5V/2A and 5.2V/2A supplies which had no problems with an overclocked Pi 2 and despite not having any USB downstream peripherals on the Pi 3.

Trying to exacerbate the issue, I tried to run some stability checks, with HPLinpack being the one favoured by most. Unfortunately, this is where I began to discover some real stability issues with my Pi 3 board. Using my Blackberry 5V/2A supply, running HPLinpack was a problem. It would flash the power LED indicating brownout, while also crashing after a few loops resulting in an unresponsive Pi. Knowing this power supply was good with the Pi 2, I decided to investigate further.


With my oscilloscope, I measured the power rails at the back of the USB connector pins (B) and at the GPIO header (A). Indeed, during heavy processing in HPLinpack, the power supply to the board is browning out but only so slightly as to just trip the supervisor chip. It doesn’t brown out so far as for me to be necessarily concerned that the CPU isn’t receiving enough power.


Zoomed, we can see the deepest dips didn’t really go below the 4.5v level, so I presumed the blinking is more a sign that the peak current draw of the CPU might be rather extreme, and maybe its own supply rails is having trouble handling it and the resistance of the polyfuse and connector contacts may not be helping.


My overclocked Pi 2 (1000Mhz core, 500Mhz SDRAM) attached to the same adapter and tested with HPLinpack showed no such issues, with the supply being a steady and almost perfect 5V.

Such instablility at load and blinking of the power LED suggests that the Pi 3 is even more picky about power supplies than ever before. The original Pi with the linear regulator was a bit of a thirsty device, but since switching to a switching converter in the + series, the consumption was tamed. If anything, I wonder if they’ve been just a little too ambitious in putting more into the same envelope.

Changing over to my Xiaomi 16000mAh power bank with a slightly higher output voltage did allow me to finish the HPLinpack benchmark, just once. Rerunning the benchmark straight after resulted in inconsistencies, indicating computational errors. The SoC was also extremely hot. Conscious of this, I tried to give the board the best chance by leaving the case open in an air-conditioned 21 degrees C room.

pi3-xhpl-bbfailThe throughput was 3.6GFLOPS, or about twice the 1.7GFLOPS I got from my best overclocked Pi 2. More performance, but stability is an issue. Reasoning it might be heat-related or power-related, I decided to blow on the SoC while I ran another test.


The unit ended up passing the test with me blowing on the SoC, which was a surprise, but the speed of the chip was still much the same at 3.6GFLOPS. As a result, it seems that the problems may be a combination of both power and heat. Having a decent heatsink fitted is definitely advisable for those doing heavy computational work to ensure stability, and a well ventilated case may indeed be a good idea.

Even where the Pi 3 didn’t crash in the HPLinpack tests, I found occasions where telltale corruption has happened somewhere, including HPLinpack refusing to run after a reboot, .tar files not being able to be untarred, and commands quitting due to Illegal Instruction or module linking issues.

stab-issue rpi3-unstable-fail-1ghz-noov

As it turns out, this problem doesn’t seem to be an isolated one, with some other people on Raspberry Pi forums noting the same issue.

A Fix to the Problem?

At this point, I was in two minds. This was one of my favourite Raspberry Pi boards to date, but if it’s not stable, it can’t be relied upon and that defeats its whole purpose. Do I try to fix it myself, or do I (hypothetically) return it and get another which may or may not be just as problematic.

Of course, as an engineer, I decide that I might as well fix it on my own as best as I can. It’s a review sample, so I’m not really eligible for a return anyway, and I don’t like taking the chance on swapping for something else that could be nearly equally bad.

Note: The following information is provided as a log of what I have done and the experiments I have run. Attempt these fixes at your own risk. I will not be held responsible for any damage, direct or consequential, as a result of using or misusing the information provided including voided warranties. You bear all risk in regards to your actions.

I started off by underclocking the device to try and assume stability. Knowing that the power consumption scales close to linearly by frequency, reducing the frequency should help give that extra margin and reduce the power consumption.

In all, I had to underclock to 1000Mhz and add an overvoltage of 2 to assume stability. Without the overvoltage, I was finding strange corruption was occuring. This can be achieved by editing /boot/config.txt and adding:


But this did not seem to me to be the optimal course of action. For one, even at this setting, I was getting LED blinks during processing, and I was sure that something else may have been “sabotaging” the power supply. This situation would have only been borderline, as a change of USB power supply or an increase in downstream peripherals would probably “change” the power budget just enough to bring back instability.

Perform the Following Modifications at Your Own Risk!

I can’t say that these modifications are new, or that they will necessarily help, but the first thing that came to mind as being potentially problematic at high peak currents is the polyfuse. A common offender in the original Raspberry Pi days, a remedy is to remove or bridge it out entirely to save the voltage drop that could occur over transients.


This is best done with a hot air gun, a set of tweezers, a header pin and some solder. This modification can potentially compromise safety in case something does short out, as there is no longer current protection on the board, and the upstream protection from the power source is being relied on.

The next point of contention was the USB socket, as I found the solder a bit thin which may impact on the mechanical rigidity as well as the pin conductivity. I reflowed and added a tiny bit of solder to the first and last pin, as well as the shell, hoping to gain a few milli-ohms.


I’m not sure this was entirely necessary, but I was voiding the warranty on the Pi 3, so I might as well go all-out.

The difference was rather interesting. No longer did I have any LED blinks when running at 1000Mhz (2 overvolt). I couldn’t run at full-stock 1200Mhz speeds without LED blinks though, so underclocking still seems to be the key.

Now, I felt that I could push the boundaries further. I couldn’t get 1100Mhz or 1050Mhz stable under any circumstances, but at 1000Mhz, I could begin undervolting significantly to save energy and heat. The reason for this will become apparent shortly.

Trials with undervolting allowed for the setting to be dialled down to -5 without instability, failing the tests at -6. As the power consumption generally has a quadratic relationship with voltage, any reduction in voltage means significant heat and power savings, which should improve the power budget.

I then overclocked the SDRAM to 550Mhz which was stable, although at 600Mhz, it would boot but lock-up fairly quickly. I didn’t feel it was worth pushing the SDRAM with custom schmoo settings or overvolt settings, so I left it there.

The reward with the casing still off was amazing – we achieved an HPLinpack speed of 5.304GFLOPS, followed by 4.753GFLOPS, 4,482GFLOPS and 4.271GFLOPS on consecutive runs. This is not a typo. Underclocking the SoC and undervolting the SoC allowed it to pass HPLinpack repeatedly and produce a faster result than at the stock settings where it could only pass the test just once at 3.6GFLOPS.

Confident with the result, I decided to shove the case on, to really “cook the Pi” to see if it would survive. Interestingly, it did.


The performance fell rather sharply as the Pi 3 heated, but then flattened out achieving about 3.3GFLOPS in the thermally difficult environment. Rather interestingly, this is not much less than the one stock run I could get, and still pretty much twice as fast as the Pi 2. Now it’s stable, and I didn’t even put on a heatsink, although I probably should.

It also points to some thermal throttling behaviour that I couldn’t resolve by monitoring clocks and temperature alone. I couldn’t see the throttling, but its effects were there. The 3.3GFLOPS run was with the case on, the subsequent 5.7GFLOPS run was when I took off the case and blew on the SoC throughout the benchmark.

when-blowing-underclocked-pi3As a result, it seems some units of the Pi 3 may well be power and thermally constrained.

My config.txt lines now have



The Raspberry Pi 3 is the best Pi ever, featuring even more performance, newer more modern 64-bit CPU and instruction set, with integrated Wi-Fi and Bluetooth capabilities. It makes it an excellent candidate for IoT applications as a hub for Bluetooth sensors or devices, or as a direct reporting platform connecting over Wi-Fi, requiring only power. Its price is fairly similar, and it has the same footprint allowing for older cases to be reused. The software has also improved, and setting up has become a little easier than before, which I am glad to see.

It does seem, however, that they may have been a little too ambitious in pushing the envelope and the unit appears to run into power and thermal constraints under high-stress loads. These are not that common, however, it would be nice to see it be unconditionally stable to avoid any chance of failures in the field.

A home remedy is to underclock and undervolt (where possible) with-or-without modifications to the board. It is also advisable to use a good heatsink and thermally conductive adhesive, and a more “open” case for ventilation to maintain error-free performance. Maybe they should begin shipping them with the boards as a low-cost way of maintaining good performance?

Posted in Computing, Electronics, Raspberry Pi | Tagged , , , , , , , , , | 4 Comments

Radio: DAB+ in Sydney (25 Nov 2016) – Service Info & Slideshows

I was contacted a little while ago by the maintainer of FMLIST, an online database of worldwide FM radio, DAB and TV information. He appreciated my posting on Melbourne’s DAB radio stations that I made in my trip down there earlier this year as the information is easy to obtain, but rarely published. Most importantly, he gave me some hints about providing the most useful forms of data for maintaining the list, namely exporting .csv, .fic and AudioInfo.txt files.

Since I reside in Sydney, and my last analysis of DAB radio in Sydney was over a year ago based on a rather crude “Magic Radio” software, I decided to re-do it with DABPlayer as a practice run as next week, I will be down in Canberra for a conference (and hoping to collect some data there as well). Of interest was that attempting to get DABPlayer to work with R820T based RTL2832 dongles was fruitless, especially under Windows 10 where the “2009” version drivers will always be installed. I had to resort to manually overwriting the two .sys files in C:\Windows\System32\drivers with the “2012” version drivers to get the latest Realtek drivers installed, but still, the R820T faultered in scanning, so I resorted to my older and more trusty E4000 based tuner.

Scanning took place in the evening (local time) of 25th November 2016, with some reception through into the early morning hours of 26th November 2016.

Station Data

For those interested in the .csv, .txt, .fic files, the station data is all contained inside a single ZIP file –

sydmux1 sydmux1-bitalloc

As in most of Australia, DAB+ radio is carried in three multiplexes, at channel 9A, 9B and 9C. The first mux at 9A has an ensemble name of DAB+ Sydney 1, and has 6.3% of the mux unused, the rest carrying audio. Reception was strong with close to 20dB SNR.

sydmux2 sydmux2-bitalloc

The second mux at 9B has an ensemble name of DAB+ Sydney 2, and was received with 16dB SNR. This is slightly weaker than the first, but still a very good signal. This mux has 13% of the capacity free, with the rest carrying audio.

sydmux3 sydmux3-bitalloc

The final mux at 9C has an ensemble name of SY abc&SBS RADIO and was received with 17dB SNR. This mux has no free capacity, with 0.7% used for EPG data and the remaining used for audio.


A total of 61 services (60 audio, 1 data) were received. Interestingly, the Service Country data seems to point to ACT/Victoria even though I am in Sydney, which is a bit of a surprise. The vast majority of stations now carry the slideshow feature. Quite a few station names have changed, but there are also new seasonal stations such as “Christmas Hope” and “Elf Radio” and others such as “EON Sport Radio”, “OLDSKOOL”, “OMG!” and “Easy Radio”. Some stations seem to have been lost or renamed – “Stardust Radio”, “LoveLand-80s&90s”, “FBi Radio”, “Apna Digital” to name a few.


A vast majority of stations broadcast in 48khz with the exception of four stations, and the majority broadcast in stereo with the exception of six. Gross bitrates of between 32kbit/s to 128kbit/s are seen, although the majority of the stations seem to be below 96kbit/s. The majority of the stations use SBR (spectral band replication) which means their upper treble content (12-24khz in the case of a 48khz sample rate) is made from intensity-coded information, and thus is not as detailed as the information in the 0-12khz band. This is a inexpensive (bitrate-wise) way to make a station sound better at lower bitrates. Some stereo stations also use PS (parametric stereo) which encodes stereo information as parameters, resulting in potentially less detailed stereo imaging but again, enhancement in quality at lower bitrates as part of HE-AACv2. Most notably, it seems all of ABC’s channels refuse to use PS encoding.

Slideshow Data

This time around, I tried to be diligent in making an effort in saving the slideshow data. I waited at least five minutes on each station for a first image, and when an image was received, waited until the whole “reel” had looped around at least twice. This process took hours to complete, as the send rate for some stations was about 800bit/s effective, resulting in images every 10-15 minutes! For the stations where no image was initially received, I came back to them and left a tuner on them for an hour to see if there would be any image sent.

Stations claiming slideshow feature but not sending images

  • 2RPH Digital
  • 2UE Lifestyle
  • Fine Music
  • Koori Radio
  • 2MFM Muslim DR
  • CW Remix
  • Coles Radio
  • The Edge
  • The 90s
  • The 80s
  • smooth fm 95.3
  • Nova 969
  • SBS PopDesi
  • SBS Radio 4

What is surprising about this list is that some of these stations had prior been observed sending images in the last catalog of DAB+ broadcasts. This specifically applies to CW Remix, Koori Radio, Nova 969, smooth fm 95.3 and The Edge. I wonder if it’s due to equipment problems which may have caused them to (temporarily) stop broadcasting images.

2SM Talk & Sport



gdrslide-png46047_c3Looks like these guys were having some trouble with their slideshow – their text is out of sync with the song being played, and the coming up/spinning now fields always contain the same data.




ZOO MusicVariety

zsdslide-png46046_f5Same thing for Zoo, but at least the text seems to be in sync with what was being played. Lots of compression artifacts due to size minimization, and their send rate is really slow.




2DayFM hit 1041

119e70066 119e70213 119e70123 119e70093

Triple M

119f58749_20 119f58749_28 119f58749_26 119f58749_24 119f58749_22

Looks like Triple M is having issues with its next song text as well.






10e138962_08 10e138962_10

Easy Radio

10e238961_b0 10e238961_e3 10e238961_d4 10e238961_ba

Buddha – Chill

10e338992_9e 10e338992_94 10e338992_91


11a455307_0d 11a455307_f8


10e038993_c6 10e038993_e9 10e038993_e4 10e038993_cb

Kinderling Kids

11a635853_8a 11a635853_8c


sky1-aimslide_95 sky1-aimslide_9b

Sky Tbred Cent

skytb-aimslide_7a skytb-aimslide_86

Of note is that it seems both Sky stations send the same graphics, but due to the time difference in surveying the two stations, I wasn’t able to catch the same images.

2OOO Languages

2ooo-101 2ooo-102 2ooo-103 2ooo-104 2ooo-105

WSFM 1017

While I did capture slideshow files on the night, they never got saved because they have the name prefixed with a path “Nexgen_XML_Export\#Digital Output\WSFM\”. As a result, I had to “create” the path by making those directories so that the images would save, so the capture of images was from the following evening.

slot_1_40 slot_2_3e

KIIS 1065

Same reason as above, except for the path was “Nexgen_XML_Export\#Digital Output\kiis1065\”.

slot_1_24 slot_2_26 slot_3_27 slot_4_29 slot_5_2b



2GB 873


Magic 2CH


Inspire Digital

insp-101 insp-103 insp-102

2SER 107.3

2ser-101 2ser-105 2ser-102

FBi Click


Hope 1032

hope-101 hope-103 hope-102



Double J


ABC Jazz


ABC Country


ABC Extra


702 ABC Sydney




ABC Classic FM


ABC Grandstand


triple j




SBS Radio 1

english_1 indonesian_1 italian_1 vietnamese_1

SBS Radio 2

english_2 indonesian_2 italian_2 vietnamese_2

SBS Chill


SBS PopAsia

slide9950 slide9960

SBS Arabic24


SBS Radio 3



It seems everything is working fine, and that DAB+ Radio in Sydney is still mostly the same stations just with a few seasonal tweaks. While almost all stations now claim to be sending slideshow data, some of them do not, and the slideshow data seems to take longer to download as less spare data capacity is available to carry the slideshow images. There are also the occasional blips with a few services where the slideshow information isn’t being properly dynamically updated, but I suppose this isn’t a major issue given that most people won’t be receiving the slideshow anyway. With the free mux capacity, it’s a shame that the quality of the stations haven’t been upgraded – this appears to be mainly a governmental decision in terms of allocation of fixed amounts of channel units to broadcasters which then all want to “subdivide” and conquer by offering a larger variety of stations rather than higher quality.

I hope you enjoyed the slideshow images. I guess I’ll soon see what DAB+ is like in Canberra when I go down there for my conference …

Posted in Radio | Tagged , , , , | Leave a comment

Review, Teardown: IKEA RYET 5w & 7.5w LED E27 Globes

It’s been a while since I had to make a trip to my local IKEA (Rhodes, Sydney, Australia), and as usual, I always like to stop by the lighting department and see what’s new. Last time, they were just introducing their LED retrofit globes as the beginning of the end of them selling CFL globes with their mercury disposal and recycling issues. This time, there was not a single CFL left on the shelves – everything had changed to LEDs.

Their original LED series, the LEDARE, was still being sold, while a newer lower-cost product line named the RYET was being promoted. This post will look at the RYET 5W 400lm and 7.5W 600lm E27 globes as they were the cheapest globes available, and I wouldn’t feel so bad about destroying them in the name of science. Also of note is that a 13W 1000lm version was also available (although it seems it is being replaced by an 11.5W version), and a few other decorative globes in other bases.

The Products

2016112316309473 2016112316319475

2016112316319474The RYET E27 globes are sold inside a folded cardboard package that has a cut-out used as an internal separator and as a viewing window to see the product inside. This design, while somewhat attractive, does expose one globe to possible transit damage – in one case, my globe had some scratches on the plastic which were purely cosmetic, but otherwise not desirable. The globes are sold in packages of two, no doubt, as a cost-saving measure compared to the individual plastic-bubbles that protect the LEDARE globes.

2016112316319476This particular globe is their 5W, 400lm version which was on special for AU$5.49 per two, making it effectively AU$2.745 per globe. That’s a pretty low price, so I really wonder what the quality would be like inside. The product code is 903.057.42 and has a batch of Week 1 of 2016.

As with all of the LED products on sale, they all reach the EU energy efficiency level of A+. This particular globe claims a 15,000 hour lifetime, with 15,000 power cycles, a CRI > 80 and 80 lumens per watt. This isn’t as high of a lifetime as some of the LEDARE or competing globes, but isn’t too bad either. The luminous efficacy, however, is quite good considering smaller globes tend to have lower figures due to power overheads. The packaging shows that the lamps are not dimmable, and comply with Australian requirements, bearing the regulatory compliance mark.


Compared with other globes I’ve previously handled, this one is relatively tiny, featuring a small neck and light weight.


It claims to consume 48mA and 5W, so therefore, its power factor is likely to be about 0.453 which makes it a low power factor device. Maybe this is one reason why it costs less. As usual, the globe is Made in China.


On my scales, it only weighed in at 33.68 grams.

2016112316319477 2016112316329479

2016112316319478The other product is the RYET 7.5W 600lm version, which is physically slightly larger but otherwise comes in an identical type of packaging. This particular product has a code is 703.216.58. The batch is Week 12 of 2016. The specifications are otherwise identical to the 5W version, although the pack is priced at AU$9.99 which makes it AU$4.995 each. Still, a very acceptable price for an LED globe.


This globe follows a more classic GLS “A” shape.


It claims to consume 65mA, implying its power factor is 0.5. Another implied low-power factor. The globe is also Made in China. It has a slightly more substantial weight …


… but not by much, weighing in at 57.04 grams. Low weight is generally undesirable, as it implies less metal is used inside, and thus less heatsinking is supplied. This would mean that the LEDs would run warmer, and their lifetimes could be compromised. This may be the main reason behind the more “conservative” 15,000 hour lifetime rating.


In the past, owing to the high cost of LED globes, and my desire to actually use them in the house (after all, I bought them with my own money), I did not really go too far with my teardowns. This time, it’s different.


As with the other A-shaped LED globes, the front plastic cover can be pried off to reveal the internals. Operating in such a manner is not recommended, as the voltages inside can be dangerous, and often, the outputs are not isolated, as the cover is presumed to provide insulation.

The RYET 5W lamp can be seen to have an internal model code of KT-A400-MJT3030-05 and KT-A55N-S0002-V00. The design is dated to 29th September 2015, and the production date of the MCPCB is Week 43 of 2015. The board is made of an aluminium substrate for better heat dissipation, and has three 3030 type LEDs mounted. As 3030-types are usually used for approximately 1W per unit applications, this unit seems to be driving them a little on the high side. The MCPCB is secured to the shell with two tapping screws.

Interestingly, in this design, it seems they have learnt from the previous messes that have been seen in soldering wires directly to MCPCBs mounted to heatsinks – getting the right amount of heat and a good reliable joint is hard. Instead, they seem to have designed a two-sided PCB shim with through-hole vias that is “pre-soldered” to the MCPCB with the LEDs, and then, a solder “bridge” is used to connect the driver to the board. As the fibreglass of the shim insulates the pad and the vias can only sink a limited amount of heat, this makes soldering the connection a lot easier – and avoids the cost of a proper connector. Smart thinking.


The soldering of the LEDs is acceptable, with the pads slightly oversized compared to the LEDs and what appears to be proper filling of solder onto the thermal connection in the rear. However, it seems the LED may have sustained some mechanical damage somehow.

Desoldering was necessary to remove the MCPCB from the rest of the housing.


Only a very minimal contact area is made between the MCPCB and the small can heatsink, namely at the edges. This is not the ideal situation, although a small amount of thermal paste seems to have been used. Some of it may have also mixed with the silicone used at the edges to hold the diffusing dome in place.


In this image, we can see the tip and can connections to the crimped E27 base. The wire is sandwiched between the plastic body and shell, and as it is stranded, it should make good contact. The tip lead is also wedged into place, and is one leg of a fusible resistor, which provides protection in case of lamp failure.


The driver PCB is also similarly named, and seems to be a design specific for this lamp. Another cost saving feature can be seen – namely the use of a single sided PCB, with very few components. There is no discrete surge protection or transient filtering capacitors, although in many space-constrained applications, it can be considered normal to omit. At least an RF-suppressing inductor is provided.


The capacitors are both Aishi capacitors from the CD11GHS (6000h) and CD11GD (6000h) series, both long-life 105 degrees C capacitors designed for use in lighting drivers. These should not pose any major issues, as my experience has been rather positive with their capacitors which are widely adopted by other brands as well.


Most of the components are mounted on the underside, including a bridge rectifier, several resistors, a diode, a capacitor and the controller IC (of which only 7 pins are used). The controller itself could not be identified, although the markings seem to show 7YL5K53K being marked on the chip.

Seeing such a fully-fledged integrated driver inside a low-cost LED lamp is somewhat surprising, as some other “Chinese” efforts on eBay use very crude capacitive dropper arrangements for simplicity and low cost.


The 7.5W version took a lot more plastic-cracking to get open, which also resulted in me gouging the MCPCB slightly. The unit also comes from the same manufacturer (it seems) with a code of KT-SS3030-34 and a date of 19th November 2015. The PCB manufacture date is Week 1, 2016. The board uses a similar two-screw mounting arrangement, and soldered shim to MCPCB contact, although the soldering is slightly worse in this model. It’s good to note that both MCPCB have wide copper areas for better heat transfer, so it seems that the manufacturers are doing something right. This one claims 7.5W and uses six 3030-type LEDs, so is not pushing them as hard as the 5W one seems to be.


Unlike the 5W version, the footprints on this MCPCB are a little on the small side, with the solder being completely hidden underneath the chip save for a small bubble at one side. The silkscreening seems to be slightly misaligned and larger than the actual chip, which gives it an odd appearance. At least the chip seems to have survived well, and although it’s a 3030 chip, it’s clear the LEDs are different in the two products (more on this later).

2016112318179505 2016112318239506

The same connection to the heatsink and to the end-cap is made, thus the comments made before apply equally to this lamp.


Unlike the other lamp, this board has a completely different design using a beefier inductor, a few polyester (non-safety rated) capacitors for transient suppression and filtering and a double-sided PCB although not strictly necessary. It seems slightly surprising that the polyester capacitors seem to have a 450V DC rating, which may mean they won’t handle mains transients so well as compared to safety-rated AC polyester capacitors.


The output filtering capacitor is also an Aishi capacitor from their RF line, rated for 105 degrees C lifetime of 3,000-6,000 hours.


The rest of the components are mounted underneath, and it seems to be based on an AP8022 switchmode power supply chip. There are a few SMD joints with solder blotches and evidence of touch-up and over-use of flux, so construction quality is slightly lacking. That being said, it seems that this driver belongs to an older product – KT-400LM-56 dated 25th October 2014. It seems that it may have been adapted from a former 400lm globe.

A quick check of isolation showed that both globes did not have isolated outputs, so should not be touched if opened. Both of them had 0.5-0.6v (one diode drop) to either live or neutral in testing, thus touching the pins when running may put you at risk of electric shock. Of course, it is designed to be used “as is”, not opened up like I do in my teardowns.


Ultimately, as I didn’t want to waste them, I decided to cannibalize two of the adapter sockets and solder in the wires directly and tape them up so they can still be used.

Electrical Performance and Testing

Driver Output, LED output

Out of curiosity, I decided to measure the driver output voltage. To my amazement, the 5W globe had a driver voltage of 141V, whereas the 7.5W globe had a 37.58V output. I double-checked and reconfirmed that this was not a mistake – the output of the 5W globe could hurt if touched!

The reasoning behind this is due to the LEDs themselves. Despite both units using 3030-style LEDs, their internal configuration is vastly different.

2016112317099497 2016112317079496

5w globe’s 3030 LEDs                                          7.5w globe’s 3030 LEDs

In the case of the 5W globe, we can see each 3030 LED package has two wire bonds – one for the positive coming into the LED chip, and one for the negative going out of the LED chip. However, the LED chip has been made in such a way that it seems to resemble an array of 15-series-connected LEDs in a 5-across by 3-down arrangement. As a result, each package has about 15 *3 = 45V voltage drop, and three of them in series gives 135V – close to the 141V measured when cold. This arrangement is quite interesting as it means that the current is kept low, which could improve the cost of the components needed to make the ballast, but at a consequence of making the output voltages not safe for accidental contact and increasing secondary insulation requirements. At least, the 15 internal junctions seem to be on the same chip, thus no additional wire bonding is necessary.

In the case of the 7.5W globe, each 3030 chip actually contains two separate LED chips, each in a long rectangular shape, connected together by an internal wire bond link. As a result, it has an extra two wire bond connections that are made, and each chip hence has a two-LED voltage drop of about 6V. For the 6 chips that are used, the approximate voltage drop is calculated to be 36V, very close to the measured value. However, this arrangement is not a preferred solution, for the same reason that some “massive array” 100 LED floodlight chips fail – wire bonds are subject to expansion and contraction stress due to heating and cooling, and these bonds are often the cause of failure resulting in LEDs that flicker until they get somewhat warm and fail altogether open circuit. The only way to know how reliable these are is to run them and see.

Based on very casual usage, it seems the light output is fairly close to the promised levels, and the light quality is acceptable for home usage. It’s not particularly special, but it’s not particularly poor either.

Warm-Up Power Consumption Trend

Both globes were left for 20 minutes to run-up from cold, with power measured by a Tektronix PA1000 Power Analyzer.


It seems that both globes were below the label rating for power consumption. The 7.5W globe settled out at just below 6.5W, whereas the 5W globe settled out at about 4.7W. This in itself is not a big issue, as it just means the power consumed is likely to be less than expected based on nameplate rating, although I cannot tell if this is at the expense of light output.

Power Parameters

The voltage provided to the globe was swept with a variac to see how it behaves under a range of line conditions.


The 5W globe seems to function correctly about 150V. This means that this globe is pretty much a 220-240V globe which cannot function in 120V countries such as the USA. The globe has a well regulated output which tails upwards slightly with increasing voltage. The power factor was about 0.55, which is considered low. This is not optimal for “helping” the power distribution network, but is common amongst households where reactive power is not something they are charged for. The converter is hence a buck converter – it reduces the input voltage, and thus cannot operate at an input voltage below that required by the LED array (approximately 135V, plus internal converter losses).


The 7.5W globe, however, showed a much wider operational voltage range, operating correctly even down to about 62V. This globe could well run in 120V countries without modification, and at a fairly close-to-unity power factor, it seems. At 230V, the power factor is 0.8, which is not as bad as expected based on the label, and is much better than 0.5.


The RYET series tries to offer an even lower cost entry point to LED retrofit globes. The packaging is spartan, and the globes are sold in two, but the price is quite attractive and the internal circuitry was of a higher standard than I would have initially expected based on the price tag alone. As usual, compromises had to be made in achieving the lower cost, with light weight, limited heatsink contact, minor construction quality issues and potentially questionable LED chips in use. The power factor was somewhat poor for the 5W globe, but better for the 7.5W globe.

However, keeping in mind the price – the advertised lifetime is less than some of the more expensive competitors, and the components used are of mostly sufficient quality, thus it seems it is a good balance for especially residential users where lights may not be used for extended periods (e.g. 24/7). The light output is of an adequate quantity and quality, based on the label expectations.

Their ultimate reliability, however, cannot be gauged on the design alone. The only way to know is to try it and see.

Posted in Lighting | Tagged , , , , , | Leave a comment