Puck.js hardware talk

Dear Espruino folks,
I've been bitten by the Espruino bug (particularly the NRF52 portion!) and while playing around with the software and hardware some questions arose concerning the interesting design decisions.
First, what was the reason for switching to the MMC5603NJ magnetometer in rev 2.1? The LIS3MDLTR seems to have a much lower power consumption and an interrupt pin...is it the annoying component shortage?
The second question is somewhat related: since the 2.1 schematic is not publically available, what is the pin configuration of the MMC5603NJ? Is the reset pin of the NRF52 free again and the SDA and SCL the same as on the LIS3MDLTR in 2.0?
Third question: as the red LED is the light sensor, what is the "infrared in" pin used for? Does it actually work as a receiver or a sensor?

Have you considered using a BME280 or so as the temperature sensor? You'd have additional interesting parameters for context awareness with a similar amount of hassle and power consumption...

Hi!

what was the reason for switching to the MMC5603NJ magnetometer in rev 2.1?

Sadly the component shortage - plus some customers used older firmware on Puck v2.0 and 'bricked' it because of the usage of the reset pin for the LIS3MDLTR

Component availability for ST chips is awful right now. We're still using LSM6DS3TR-C but for the batch we're making now they were very hard to find and I had to pay double price for them.

The second question is somewhat related: since the 2.1 schematic is not publically available, what is the pin configuration of the MMC5603NJ? Is the reset pin of the NRF52 free again and the SDA and SCL the same as on the LIS3MDLTR in 2.0?

Yes, that's right - sorry - I just put it live at https://github.com/espruino/EspruinoBoard/tree/master/Puck.js/pdf

Third question: as the red LED is the light sensor, what is the "infrared in" pin used for? Does it actually work as a receiver or a sensor?

That was the intention, but sadly I never had any success with it. It may be possible to set it up using the PPI peripheral to charge the LEDs and count how long they take to discharge with https://www.espruino.com/NRF52LL#hardware-capacitive-sense-on-two-pins but I haven't had time to try that.

It is however useful for the self-test, since the Puck can check that the IR leds are attached and that the FET is working.

Have you considered using a BME280 or so as the temperature sensor?

Yes, but the BME280 is £2.89 at 500-off, PCT2075TP is £0.35 - so it's a lot pricier.
And on top of that the case is sealed-ish, so the Humidity and Pressure aren't that useful. It didn't seem worth adding extra cost to the Puck for a feature that users would have had to have drilled a hole in the case for :)

Thanks for the info and the schematic Gordon.
This component shortage really sucks. As you said in another thread, a simplified puck.js totally makes sense, something similar to the "custom beacon kit". Some time ago I actually started creating my own version, because they are so hard to get.
How does the current Puck.js firmware adapt to the different puck versions that are around or handle the situation if sensors are missing? For example if you had a "purpose-specific puck" with only the IMU mounted, would the firmware start up nevertheless, despite the missing magnetometer or PCT2075? Or does it make way more sense to compile a custom firmware?
Greetings,
Arthur

How does the current Puck.js firmware adapt to the different puck versions that are around or handle the situation if sensors are missing?

It scans for which I2C magnetometer is connected at startup and figures out which version it is. As long as it gets that right, other stuff will work even if one device is missing. Even if that fails the rest of the non-I2C device functionality will work.

I'll make the firmware function on Puck.js Lite, but likely I'll make a new build for it which will leave a bit more space for Storage.

Or does it make way more sense to compile a custom firmware?

It probably makes more sense to do a custom firmware. If you have no external hardware, just use the MDBT42 firmware though

It scans for which I2C magnetometer is connected at startup and figures out which version it >is. As long as it gets that right, other stuff will work even if one device is missing. Even if that >fails the rest of the non-I2C device functionality will work.

Thank you! That's a clever way of solving the version problem, but it means for me that I have to mount a magnetometer :). Maybe I'll wait till June and just buy a 2.1 because the whole project is converging towards the existing versions anyway lol