Latest pHAT Batch has firmware that is incompatible with the python library.

[ryanteck]

First off my apologies for the delay in getting this issue resolved, as we're launching some new products on a tight schedule so I've been super busy working with that.

As a first step I wanted to setup this new issue with a more detailed diagnosis of what's caused this issue, what the plan to fix it will be and answer some questions.

So what's caused the issue?

The most recent batch of pHATs have been programmed with a newer firmware, of which the manufacturer of the Radio module we use decided to change significantly the commands the module uses so the commands the Pi issues aren't no longer what the Module expects.

This has caused the latest batch to break, it isn't common for a component like this to change the way it communicates without for example changing the part number or maintaining some level of backwards compatibility.

What's the fix?

There's two possible fixes to work around this.

1. Firmware Downgrade - It is possible to downgrade the firmware on the modules, while not a complicated process it is a process that we'd need to document and perform a few times ourselves to ensure it works. At the same time we currently don't have the capacity to re-program the rest that are sitting in stock as some distributors may already have received stock of these so we can't ensure they would all be done.

2. Update the Library - This is the route we're going to try and do, essentially it shouldn't be complicated just more a time consuming task. This would however pose the issue of which version of firmware is the unit running and matching this to the version of software.

It's likely that for now we'd then have the two versions of software with the default then being the newer one but keeping it possible to still install the old one.
,
Later on it would then be nice to integrate the ability for the same version to either support both and automatically detect, or have a flag in the software. However I think to begin with the main focus will be a new version just supporting the new one.

Why has this happened?

The first few batches came with the original firmware as default and later batches we got the supplier of the modules to keep with the older version to prevent this from happening.

However for the latest batch a miscommunication issue happened and instead the latest set was shipped with the newest firmware sent.

Why wasn't this picked up in testing?

While quite a lot of our products are tested to a further extent, these undergo only an electrical test during production to ensure all the electrical traces are correct and a full test isn't performed.

As the firmware isn't programmed by us, it's not something we would have checked for compared to other products where we program firmware onto the modules.

Until this batch, I believe we've had a <2% failure rate which is why we've not had to add extra testing during production.

TL;DR

The latest batch unfortunately has a new version of software that causes them to not work, I'm working on getting a fix out ASAP.

If you've got any other questions feel free to post them above and I'll try to help out where possible.

[ryanteck]

Relates to AmedeeBulle/pyrak811#15 AmedeeBulle/pyrak811#16

[EdwardHanlon30]

Hi Ryan,
thanks for the update and explaination

[markus1203]

Thanks for the information! Can you estimate when the library update will be ready?

[hohenstaufen]

I have just received some HATs and they are unusable due to this problem. What solution is currently working?

[Ville-Eloranta]

I have found a working solution by using pyrak811v2 library.

[ggal]

Hi Ryan, can you please document the firmware update problem? Even converting to the pyrak811v2 library I'm having issues and would like to downgrade to the known working firmware.

[reese-grimsley]

Hi Ryan, I wanted to poke in on this problem again. Is there any way to circumvent the issues, even by directly sending AT commands over serial? Is it something deeper in the chip that has changed, that won't be accessible over serial? I guess I'll answer some of this below, as I started digging deeper.

I'm seeing activity on the pins with the existing RAC library - using 'tail' on /dev/serial0 after I echo to that serial port shows that it gets back a response that just says "ERROR: 1", which indicates the AT command is not supported. I've been throwing otherwise valid commands into /dev/serial0, and it always responds with that "ERROR: 1" string. If the chip has a totally different command structure or set of commands, that seems like a pretty bone-headed move; I can't imagine that's the case, right? That's what it sounds like, but I don't see any documentation from RAK that suggests this. If you know of some, I'd appreciate if you could post a link.

Interestingly, the interface changed after I called "at+boot", at which point it started responding with different messages, though no more helpful. Basically just turns into "AT not support.\r\n". Then I tried a few more commands, but there was no response whatsoever. Edit: Every so often (not consistent), it gets a spark of lucidity, where the device responds to an AT command; it said "RUI Bootloader:3.0.5" when I hit it with the 'at+version' command, but never did so again. Curious.

It comes across like it's not entirely the python library that's the problem, but the firmware in the chip itself; is there a way to change the firmware on the hat itself to use an earlier version, or am I stuck with whatever >3.0 is on here? You mentioned downgrading -- I'd be curious to know just a little about that. I'm very interested in getting some fix quickly, even if I need to do some grunt work.

Thanks!

Edit: my radios started working better overnight, such that they're actually responding to normal AT commands at this point. This python library doesn't work, but the other one seems to be. I have some strange behaviors with the thing earlier, but I believe I had unintentionally put it into bootloader mode ('at+boot') such that it wouldn't recognize the ordinary at commands. Responses are more normal now.

[AmedeeBulle]

The v3-firmware development branch has LoRaWan support for the latest pHAT batch.

Support for LoRA P2P will be available soon.

[AmedeeBulle]

LoRa P2P support has been added (still in the v3-firmware development branch, but will be merged soon)

pip install rak811==0.8.0.dev2

[AmedeeBulle]

0.8.0rc1 adds UART support.

Unless issues are found, it will be merged in the main branch soon.

[AmedeeBulle]

rak811 0.8.0 has been released, code merged to the main branch.

There is not code difference since 0.8.0rc1.