The WiFi HAT

http://shop.elesar.co.uk/index.php?route=product/product&product_id=83

A very interesting product. I have three questions, that will probably help some other users:
- Is this kind of hat compatible with the official case? (Pi A or B)
- Could the price really go down with volume (10 or 20 cards bought)?
- Need to solder something?

A lot of people stop today their RISC OS evaluation because of the lack of WiFi.
So this solution is just fantastic.

Hum, I’m stupid :)
“with no soldering required”

Hmm, interesting find David.
Quite an extensive feature set even if the current package is totally complete (elements to come in upgrades)

The link you gave produced a page not found so things have moved around a little since you looked.
This worked for me –
http://shop.elesar.co.uk/index.php?route=product/product&path=20_46&product_id=83 in which we have:

Only suitable for use with RISC OS, the WiFi HAT requires a RISC OS soft loadable driver module (see resources)¹. Includes an easy to use desktop WiFi Manager, which lists the nearby access points as well as displaying the current connection status. Due to its tight integration with RISC OS the remaining familiar Internet tools in !Configure are used to set up the networking and monitor its status.

Selecting a network is a simple matter of choosing from the WiFi Manager’s menu and entering a password. For networks that you visit frequently, the password can also be stored to eliminate all the typing; if the network is in range at boot time the link will be automatically re-established.

and

In the initial release of the software a few minor restrictions are in place. They are:

• There is no box to enter a username when joining a network secured using RADIUS. This is supported internally by the firmware, but can’t currently be accessed via WiFi Manager’s dialogue boxes.
• It isn’t possible to automatically rejoin a hidden network at boot, though you can manually join at any time. This is not supported by the firmware, and is awaiting more information from the chip vendor.
• WiFi Manager doesn’t speculatively scan for known networks when you are not connected to any. This is expected as a future enhancement.
• The ‘via ReverseARP’, ‘via BOOTP’ and ‘from CMOS’ methods of obtaining an IP address aren’t supported (‘via DHCP’, ‘manually’, and ‘from hostname’ are) when swapping between networks. This is expected as a future enhancement.
  

I’m thinking Elesar have a product that will be available at the stand this weekend. I hope they have a good stock as I suspect most visitors with a Pi will be wanting one.
I can’t help wondering whether there’s a hardware/firmware dependency in this or whether this is an early stage of the overall WiFi support.

Note: Offloading elements of the network connection work to the NIC is regularly done in the MS PC world to improve throughput.

¹ Resources
EtherWILC WiFi driver
RISC OS boot sequence update to load the EtherWILC driver module on RISC OS.

Received mine this morning and I’m posting this from my Raspberry Pi running RISC OS on wifi! Hurrah!

A few early notes:
- it’s a HAT (Raspberry Pi parlance), so no soldering required. You literally push the HAT into place on the GPIO pins.
- there’s no pass-through like on some HATs so you lose access to the GPIO pins (although you could at a push, I guess, solder directly to the underside of the pins on the WIFI hat.
- it’s a very slim HAT. I haven’t tried a case on it, but there’s a good chance most cases will fit. My Pi is VESA mounted to the back of my monitor which is why it’s case-less.
- the driver module is called EtherWILC and is installed via a !Boot update from the Elesar website.
- there is a status LED on the board.
- the interface appears in Network configuration under Interfaces. The manual says “ensure that only one of the interfaces in the dialogue is ticked”.
- a quick reboot later and I now I have a WiFI icon in the Iconbar beside my drives. The menu immediately shows any networks it has found, and the signal strength is displayed under an Info submenu.
- selecting an access point prompts for a password and… that’s it, assuming you’ve chosen DHCP.

I haven’t done speed tests and the like yet (the postman only delivered it an hour ago!) but it just works and I’m very pleased as I can now disconnect the annoying USB-Ethernet adapter from my MacBook Pro and the Ethernet cable that snakes across my desk.

If you want to pick one up at the show, you can order it on the website for collection, saving you a couple of quid and guaranteeing you’ll get one. I’m sure this is going to be a big seller, so if you want one, you might want to get in there quickly.

As I said, I’ll do more tests but at this early stage I am very pleased with it.

1) Is this kind of hat compatible with the official case? (Pi A or B)

The outline follows the foundation recommended HAT outline, and the overall thickness is 4mm (1.6mm for the PCB and 2.4mm for the electronics). The 2 pin header shown in the photo is to enable writes to the ID EEPROM which isn’t needed in normal use so could be removed if height was an issue.

2) Could the price really go down with volume (10 or 20 cards bought)?

There are 25 HATs on a panel so there’s an administrative saving for any multiples of that, beyond that you’d need to get to 100’s to gain significantly. For example: a solder paste stencil costs £250, so amortising that over only 10 is £25/HAT, amortising over 1000 is 25p.

3) Need to solder something?

The elves at the factory do all the soldering.

The link you gave produced a page not found so things have moved around a little since you looked.

Both links given are correct, the ‘path=20_46’ bit in the middle is just so the right breadcrumb trail is shown, but not essential.

Both links given are correct, the ‘path=20_46’ bit in the middle is just so the right breadcrumb trail is shown, but not essential.

Theoretically – however in practice using Firefox the link David gave drops out to this page with a message “The page you requested cannot be found!” displayed in the lower portion.

On IE11 the redirect to http://shop.elesar.co.uk/index.php?route=product/product&product_id=83 occurs.
Some quirky code in the breadcrumbs?

Theoretically – however in practice using Firefox the link David gave drops out to this page with a message “The page you requested cannot be found!” displayed in the lower portion.

In my practice with Firefox, the link from David just worked.

But nobody understands The Web nowadays…

In my practice with Firefox, the link from David just worked.

Just as it does for me, now.

But nobody understands The Web nowadays…

Some people do (I’m thinking Sprow made a change), some don’t (reference the certificate errors I mentioned some while back on provider web sites, and more so a certain agency that’s supposed to guide, direct?, things digital for my employer).

It depends – as the link is displayed in the first post, it will fail if you click on it as a link. In Firefox in Windows, if you highlight the whole URL, extending past the ‘link’ to the end of the line, then right click on the highlighted text, Open Link, it will work.

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…?

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?

Does the RTC not allow anything stacked on top of it? Or are we talking about two items needing the GPIO pins and wanting exclusive access?

One solution would be to make the Hat available without the 40 pin socket and allow the user to solder a long-pin socket so that it can be stacked.

RTC should be not a problem. Use I2C and only one time at boot, as I remember right what Jeffrey wrote a “long time” ago.
I use a RTC and a battmanager on the same I2C bus. No Problem. Also not with Pi-Top.
I think someting like serial e.g. GPS and WIFI could be a problem but not sure.
A long-pin socket could be an easy solution.
I have solder my RTC direct (Pi bottom) and can use all GPIO pins if I need. ;-)

Does the RTC not allow anything stacked on top of it?

Mine fit on the 6 pairs of pins away from the USB sockets. They do not have pins showing above. My two are both CJE offerings – I do note that there are now many more variations available, some with pass-through headers, although that may well require taller cases!

Whether they would clash on access to the same GPIO pins is obviously another question.

Whether they would clash on access to the same GPIO pins is obviously another question.

The RTC uses I2C whereas the WiFi Hat appears to simply be a WiFi-SPI bridge unit, so they shouldn’t clash on GPIO pins / device IDs. You’d need to get an RTC with 40pin pass-thru header and then plonk the WiFi Hat on top of that, which would make it a bit tall but should work. It would be nice if the WiFi Hat was available with pass-through pins too, so you could still use the GPIO pins. Given how much I use GPIO, then if I got a WiFi Hat I’d have to take the existing header off and fit a pass-through one myself (hello voided warranty!).

beyond that you’d need to get to 100’s to gain significantly.

Interesting.

I work on a project under RISC OS, with three modes of delivery:
- Appliance: needs WiFi; solved.
- Emulation: needs user mode network in RPCEmu (etc.); solved?
- Cloud: I need to make some tests with ROS on Linux
(and https://www.scaleway.com/en/virtual-instances/arm-instances/)

In my practice with Firefox, the link from David just worked.

Seems to be a bug in the forum.

Seems to be a bug in the forum.

Textile hates you and messed up your URL on purpose.

Feel free to try to analyse Textile’s inner logic, how it does stuff, and why it does what it does.
First your head will spin.
Then it will explode, Scanners style.
Then you will agree. Textile is a sentient creation that lives for subtly mucking up messages. It likes trashing code the most, because it knows that typos and weird in textual messages aren’t that big a deal, but one single changed character in a piece of code will invoke a world of pain.

…

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?

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

the motivation seems to be simplicity – the foundation wanted an expansion concept that ‘just worked’ without needing to fiddle with ISA card jumper settings and similar, and most of the signals on J8 are point-to-point anyway unlike a typical data/address bus.

That said, there’s nothing using the main IIC bus on the WiFi HAT, so as Andrew suggests an RTC from CJE with long pins will work electrically albeit a bit tall mechanically.

An OLED module and a RTC from CJE (which both use the IIC bus) could (both) be plugged in electrically, just need to think how to arrange it mechanically. Does the WiFi Hat use the serial port pins 8 and 10 (RXDATA and TXDATA)?

One thought for the Pi 4 – could a keyboard be attached using the IIC bus (no USB on Pi 4)?

That said, there’s nothing using the main IIC bus on the WiFi HAT

Perhaps, if board real estate permits, an RTC could be built on the WiFi HAT?

Better still, could the WiFi Hat use the unused real estate to have some development tracks like ProtoPAL or similar. The user could then add something simple.

That’s why many EEPROMs have a link for setting the IIC address. This could be “recycled” in hats as to be “first”, “second” [, “third”] board. The address of the EEPROM will give the board level, and it’s priority (if necessary). Yes, this means a jumper or two. Not the end of the world. Indeed, a weak pullup (or pulldown, as appropriate) could have a default board with no jumpers. Plug’n’plug. Only reaching for the settings if and when necessary.

Certainly, there’s a lot of stuff that could be hooked to GPIO, so restricting a hat to literally claiming them all (even if not using them all) is rather careless for a device aimed at "maker"s…

the motivation seems to be simplicity

Simpplicity is not reaching for a soldering iron just to get the RTC working with something else. :-)

Certainly, there’s a lot of stuff that could be hooked to GPIO, so restricting a hat to literally claiming them all (even if not using them all) is rather careless for a device aimed at "maker"s…

I guess the HAT Specification is designed for those users who wish just just ‘plug and play’ with their add-on boards without possible problems, and just assuming that a lot of HATs would be swapped over rather than anyone wanting to stack them. Follow the official HAT Specification and you get to officially call your board a “HAT”, which looks/sounds good but comes at the expense of usefulness! Of course, if you use one of these like I do then you get round the problem another way anyway. Plus I’d guess the majority of add-on boards don’t conform to the spec, which means you can use them together, even get one board controlled by another add-on (see my various IIC inputs which can control some of the little LED add-on boards).