The WiFi HAT

You need a hat stand.

You need a hat stand

One of these ?

Nice find.

Link to the official site: http://www.piface.org.uk/products/piface_rack/

Aha, thanks. I knew what it was called, and Google image searched to find it. Should have just looked it up properly! Shame they didn’t do a 40way one too!

I suppose the built-in (Broadcom?) chipset on the Pi must be a nightmare if it’s easier to replace it…

I suppose the built-in (Broadcom?) chipset on the Pi must be a nightmare if it’s easier to replace it

The point is that to use the on-board wifi we need an updated network stack (see the Network Bounty ) whereas the SPI-Ethernet board used in the WiFi Hat does everything for us so can be used now.

The point is that to use the on-board wifi we need an updated network stack

The same problem with USB WiFi dongles?

The HAT specification doesn’t allow for piggybacking HATs, for 2 reasons:

There would be no way to marshal who in the stack had rights to use which pin, or resolve clashes (or at least not without each HAT having a mux on every pin!)
The ID EEPROM is at address &A0 on the ID IIC bus (not the main IIC bus), and again no way to deal with what would happen when multiple ID chips are wired in parallel

My understanding therefore (after some discussion on Friday) is that the SPI pins on the 40 way connector (pins 19, 21, 23, 24, 26), the aux IIC pins (27, 28) are used. I can also see connections to pins 31, 32, 33 and 35 on the circuit board. Apart from power and ground, are these pins all used and no others please?

Apart from power and ground, are these pins all used and no others please?

Here’s the table of used pins

So GPIO2/3/4/13/17/27/22/5/14/15/18/23/24/25/16/20/21 are unused.

Many thanks for the information.

I just want to share my first impressions with the WiFi HAT on my Raspberry Pi 3. Installation was really easy. The hardware can be attached to the raspberry very easily and seems to fit quite well even without using the supplied screws. Installing the software is as easy as you would expect on RISC OS (basically merging !Boot – ok, you need to set the ethernet settings as well). Also connecting to my wifi network was really easy and like on any other operating system, so you can just select your prefered network from a list of available (visible) networks, enter your password and you are connected. After the first reboot I was not able to browse with netsurf – but maybe this was a netsurf problem, now it works. There is a small printed manual which explains everything you need to know (except where to find the download link for the driver – it’s on the elesar page where you find the wifi HAT). So for me it really makes a difference because at my desk I do not have ethernet and I think this will be the starting point for me to migrate from VirtualRPC to the Raspberry PI.

So overall I like the WiFi HAT very much and I think it is a fair offer given the low volume of sales compared to “normal” USB WiFi sticks.

Some points could be improved in future but didn’t bother me too much:
– when attached the raspbeery doesn’t fit into the standard case anymore and given that the module is quite empty I wonder whether it would be possible to shrink it just a little bit so that it fits
– Only 2.4GHz, 5GHz would be nice
– small on-board antenna just gives me around 50% signal strength which seems to be ok. Still: a connector for an external antenna would be nice
– iconbar icon is static and does not indicate signal strength
– on the raspberry pi 4 I could imagine that cooling the cpu is more difficult if the WiFi HAT is attached

But I am happy that there is a very nice solution now to connect to a WiFi using RISC OS.

– Only 2.4GHz, 5GHz would be nice

A lot of hardware is still “only” 2.4GHz.
At work they have put an access point into the staff break room. It only works on 5GHz. Accordingly an awful lot of smartphones cannot see it.

I try to explain. But I give up when I get asked what I’m on about, they haven’t brought out 5G yet and anyway it’s nothing to do with WiFi.
How do you explain to… shall we say… less intelligent people… that 5GHz is not 5G? <facepalm>

– small on-board antenna just gives me around 50% signal strength which seems to be ok. Still: a connector for an external antenna would be nice

Yes, a tiny antenna connector shouldn’t add much to the cost/design but could give opportunities.

However be warned. I tried a 2.4GHz antenna (pinched from an old router) in my IPCAM instead of the built-in antenna that was basically just a cable going to what looked like a little leftover from a bad plumbing job. With a proper WiFi antenna, reception was worse.
https://heyrick.eu/blog/index.php?diary=20170222 (deeper hacking, about halfway down the page)

– iconbar icon is static and does not indicate signal strength

Hmmm, I’ve written a little tool to report the signal strength of my Vonets. It queries it every 15 seconds. I don’t use it much as my signal strength is rubbish and I know it. But, just kind of wanted to see if I could do it.

I suppose it depends if that information is easily available from the hardware.

By the way, the trick to getting changable icon bar icons working is to have an icon where the sprite name is indirected. Change the sprite name in the bit of memory reserved for the indirection, then call Wimp_SetIconState with EOR and Clear words both as zero. This will cause a redraw, which will pick up on the new icon.
Note: beware of transparency. ;-)

– on the raspberry pi 4 I could imagine that cooling the cpu is more difficult

There. Fixed that for you.

The Vonets adaptor is cheap, but you need the nouse (and probably another computer) in order to set it up. Especially given the eccentric translations and it asking questions and offering options neither of which are mentioned in the installation guide. And I use the word “guide” loosely.

This sounds like plug-and-play for RISC OS, which is a good step forward.

For me it is only interesting for my portable devices.
Works more than less but needs any mechanical (V2) or solder (V1) works. ;-)
Short report…
V2: Works with a V1 protoboard …

… but the sandwich is to high. Remove the “socket” from protoboard and shorter the pins. Rasp a bit from the HAT header gives an other mm ;-)
PL1 must be removed… Than you can close the keyboard.
I have any Problems with one of my protoboards. Three HAT using pins are def.

So I have made a cable. Only the HAT-used pins are connected.

V1: Is a bit more problematic. E.g. the PiTopHub uses SPi for “power off” and “brightness”. The HUB has the control.
I use also a protoboard but without changes it will not work.
Have made a cable and reduced the protoboard pins to PiTopHub…
“At the end of the day” the HAT becomes the needed pins and the PiTopHub only the rest. That works.

The cable now in the case ;-)

I just want to share my first impressions with the WiFi HAT on my Raspberry Pi 3 […installation steps…] After the first reboot I was not able to browse with netsurf – but maybe this was a netsurf problem, now it works.

We noticed that too when helping set up a customer a few weeks ago. The sequence of events

• Enable the interface, with DHCP, but not yet joined (because on first install WiFi Manager isn’t yet running)
• Restart
• Now join
• WiFi Manager tries to trigger a DHCP but this times out, and you end up with a default private network address

turns out to be a bug in NetTime which meant it swallowed all the events for socket 0 which were supposed to be destined for the DHCP module. This has gone unnoticed on RISC OS 5 because normally you have to reboot when making such a change, but WiFi Manager is breaking new ground with hot retriggering of DHCP (such as when changing networks). There’s a fix queued up so once that’s made it through the review process we’ll provide an updated !Boot to merge.

Fortunately it only happens the very first time round, after that the AP is in the list of known networks.

– when attached the raspbeery doesn’t fit into the standard case anymore and given that the module is quite empty I wonder whether it would be possible to shrink it just a little bit so that it fits

The shape of a HAT is governed by the HAT specification, though there was feedback earlier in this thread that people might like to see the spare space near the flexi cable slot used for a real time clock & battery.

– Only 2.4GHz, 5GHz would be nice

It’s taken since 2015 to find a chipset that will integrate with the existing RISC OS network stack (including a few false starts of chips that looked great but turned out to be turkeys). 5GHz would be nice, but at present the supported family is 2.4GHz only. It’s a useful technology to have in the bag for some other projects Elesar has, the HAT is a convenient byproduct we can release now.

– small on-board antenna just gives me around 50% signal strength which seems to be ok. Still: a connector for an external antenna would be nice

There is a variant which comes with a UFL connector. We opted not to offer that because for each different antenna that might be provided we’d need to redo all the testing (radio testing is very expensive!); a built in antenna avoids those combinations and permutations to reduce costs.

– iconbar icon is static and does not indicate signal strength

That’s already on the feature request list. Watch this space…

after that the AP is in the list of known networks.

Hehe… I’ve just discovered that the <cough> other adaptor </cough> filters APs by SSID and MAC address. So my plan to have a duplicate Livebox with the same SSID and password works for every single device except the Pi’s WiFi. Because the MAC doesn’t match.

Maybe this weekend, I’ll plug the thing in, fix it up, and switch over to the Livebox Play I was given (my others are Livebox 2).

Why do this? Well, readers of my blog will know that a lightning strike nuked my Livebox a while back, so I have bought a couple from vide greniers (boot sales) and duplicated the settings on them so that if there’s ever a hardware failure, I can basically swap out the dead unit (to get Orange to replace it as the provider-provided one is a rental) for a working one and keep on going. This is vitally important not just because of internet access, but also because it is the landline telephone. No connectivity, no phone. [not that anybody ever calls]
It works perfectly, except for this one device. Grrr…

There’s probably a setting to turn this off, buried under a sleeping tiger after three layers of Chinglish and a blood sacrifice.

used for a real time clock & battery.

Yes. It seems to me that having a clock on-board would be a very good idea. Thanks to CJE, my primary Pi has a clock on-board, but I do miss the functionality on all the other devices. Sure, one can use NetTime, but this rather implies that the machine is connected to the Internet. Which isn’t guaranteed even with your WiFi hat (AP/internet down, out of range, somewhere else?). An RTC has been a necessary thing in home computers pretty much ever since floppy discs made timestamps a thing – so we’re looking at “since the 8 bit era”. It’s a surprise that the Pi doesn’t have an RTC inside the SoC awaiting the addition of a battery (like the Beagle family).

5GHz would be nice, but at present the supported family is 2.4GHz only.

It would be nice, certainly, but at this state in time I’d say (from experiences at work with the 5GHz-only AP) that over half of people’s smartphones (at work) do not support 5GHz. I was actually surprised that the cheap little HP 3630 printer seems to (playing with Livebox Play) because, well, nothing else asides from my S9 does! Those ESP32 and ESP8866 (or something like that) modules? 2.4GHz.
I don’t imagine the older frequency will be going away just yet. And one can argue that signals are better on 5GHz precisely because so few devices use it that it isn’t laden to hell and back like 2.4GHz is. ;-)

We opted not to offer that because for each different antenna that might be provided we’d need to redo all the testing

I believe the OP wasn’t asking for an antenna, just a socket. If you provide the built in antenna via a zero ohm resistor and a UFL socket; you get that approved, and leave the antenna issues to the user if they wish to do so.
The Vonets has sockets. The Livebox Play has sockets. Neither are specifically intended to be user-upgradable, but the choice is there if the user is handy with a screwdriver and a soldering iron. Of course, the usual “voids any warranty” will apply to such modifications…

Just taken a look at the board (link). That with an RTC (and, please, a header for IIC for daisy-chaining extra stuff) would be a worthy addition to a Pi – especially since it cohabits with the Pi itself, meaning no extra power connections, no cables, no extra bit of hardware to lug around… And the best bit? You don’t need a PC to set the thing up in the first place. WIN!

turns out to be a bug in NetTime which meant it swallowed all the events for socket 0 which were supposed to be destined for the DHCP module.

I can’t help wondering how many of the time sync problems on DHCP people have mentioned are related to this specific bug.

This has gone unnoticed on RISC OS 5 because normally you have to reboot when making such a change,

Which I’ve always regarded as a bug in the RO stack – sort of bearable if you’re starting the device with a manually assigned IP, but there the tolerance ends.

The shape of a HAT is governed by the HAT specification, though there was feedback earlier in this thread that people might like to see the spare space near the flexi cable slot used for a real time clock & battery.

I made the suggestion initially on the grounds that it simplified the problem people had with mounting both WiFi and RTC and probably didn’t massively increase the production cost of the WiFi

We opted not to offer that because for each different antenna that might be provided we’d need to redo all the testing (radio testing is very expensive!);

I believe the standard way of sidestepping such costs is to test with one antenna and recommend that people purchasing the add-on take that from you or a.n.other supplier. Should the customer purchase a non-recommended antenna then…

That with an RTC […] would be a worthy addition to a Pi – especially since it cohabits with the Pi itself, meaning no extra power connections, no cables, no extra bit of hardware to lug around… And the best bit? You don’t need a PC to set the thing up in the first place.

RTC, WiFi and set up with QuipZilla. ;-)

b*****y Textile

My RTC (now) are inside the “sandwich”…

(e.g. V1 … without cable and HAT)

We opted not to offer that because for each different antenna that might be provided we’d need to redo all the testing

I believe the OP wasn’t asking for an antenna, just a socket. If you provide the built in antenna via a zero ohm resistor and a UFL socket; you get that approved, and leave the antenna issues to the user if they wish to do so.

At 2.4GHz the bit of track going to the depopulated zero ohm resistor will be a surprisingly good antenna, or at the very least cause a mismatch requiring trimming out with a network analyser. If you can round up 24 friends also wanting just a UFL socket the MOQ for something custom is 25, drop Elesar a line.

turns out to be a bug in NetTime which meant it swallowed all the events for socket 0 which were supposed to be destined for the DHCP module.

I can’t help wondering how many of the time sync problems on DHCP people have mentioned are related to this specific bug.

Unlikely to be any – NetTime is loaded from disc, so is sitting higher up the vector chain so always got a look in, and since DHCP had done its thing already it was mostly idle.

So if using the WiFi HAT means the GPIO pins are not easily available for other connections, does that mean a RTC cannot be plugged in? Surely many users have fitted an RTC for RISC OS use? I do realise that NetTime will set the time if online, but if offline…?

Good news Martin – some space has been clawed back and now there’s a variant of the WiFi HAT with a real time clock (order code EA-846-9) so you can keep things ticking when offline and connect without wires. Batteries are included.

The description on that page says that the current version of the driver is 1.04, but the download link returns 1.03.

the current version of the driver is 1.04, but the download link returns 1.03

Now corrected (dragged & dropped one directory higher up!).

Yep, good now… and I have a fancy strength meter now! :)