Uniquely Identify My Mainboard?

Hi All;

So I’m gathering data, and while I can uniquely ID based on the MAC when I have an ethernet adapter, I’m moving to wireless/gateway in my next iteration with some xbee modules. Can anyone advise me on how to best have a gadgeteer device uniquely identify itself in a consistent manner?

I’ll likely have a Cerbuino Bee with an Xbee module and a sensor or two, talking to a Cerberus or Spider which will then talk to an Azure API. I need to ID the Cerbuino Bee in such a way that I can track it’s readings among a group of sensor devices.

I’ve asked an a-like question before, lots of reads but no single sofar after 17 days … a unique serial number or the possibility to write somewhere in the config area a generated guid so you can distinquish even if you have multiple boards of the same kind.

At the moment I’m tagging the board with a in the program hardcoded ID.

If you are using XBee’s you could use the XBee address which is the unique serial number for that XBee.

1 Like

@ PiWi - Yeah, the ConnectTheDots sample code says “put GUID here” which is great until you have 30 devices or more to deploy.

@ Sprigo - Aah ok, since everything I run will have either a network adapter or an xBee, I should be good to go.

Any chance you have code to get the ID off the xBee?

There’s the GBee library on Git which I have used in the past. Unfortunately it’s currently only available for 4.2 but full source code is provided.

@ Sprigo - Awesome, thanks!

@ Squeebee - You’re welcome.

You can use this code to uniquely identify each cerb family board…

             using     GHI.OSHW.Hardware;
//this is for framework 4.3 and higher
              using   GHI.Processor;

//check if this is a Cerb Family board
             if (DeviceInfo.GetDeviceID() == DeviceID.FEZ_CERB)
                  //create an empty byte array to hold the unique Deviceid of STM32F4
                  var deviceid = new byte[12];
                  //read the address where the unique id is burned.
                  GHI.OSHW.Hardware.LowLevel.AddressSpace.Read((uint)0x1FFF7A10, deviceid, 0, 12);
//this is for framework 4.3 and higher
                 GHI.Processor.AddressSpace.Read((uint)0x1FFF7A10, deviceid, 0, 12);

The stm32f4 has a unique serial number integrated :slight_smile:
You can also use my code here to generate a unique GUID or a MAC address based on a string or the above unique id in case of CERB board :slight_smile:


@ Jay Jay - Cool, so your code will generate a unique MAC for the device, that is consistent with every startup? That sounds better since it won’t depend on the mainboard type!

Yep ;D

Won’t this code generate the same MAC address for each board unless the seed is unique for each board? The OP wants a unique ID for each board.

If it’s a Cerb family board, the mac will be unique for each board because the seed is the unique serial number burnt in each smt32f4 chip. As for other boards like spider and raptors, you can skip them since they all come with a unique MAC from the manufacturer (ghi) or you can use a simple unique hardcore string per board.

@ Jay Jay - Aah, use your MAC code in combination with the serial # code, got it!

It kind of strikes me with surprise these pieces of mem are filled with 0xFF and not with real numbers. I’ve not seen a board using these, pretty obvious places of info ??

And if MFDeploy can find it, we certainly can too. After all, it’s open source now right ?

I refer to the HalSystemInfo. part in the picture.

1 Like

@ Jay Jay - Ok, what Reference provides GHI.OSHW.Hardware?

@ PiWi - Setting those values seems reasonably straightforward and I can even imagine a post-compile step that you could use set them by fiddling with CONFIG.hex before each MFUpdate. The trouble is, they are not exposed in managed code anywhere, so you would need special firmware or an RLP add-in to read them.

The other values near there are read in Framework\Core\Native\HW_SystemInfo.cs, so one could either expand that class or create an RLP to read the moduleSerialNumber and systemSerialNumber. It kind of baffles me as to why those were not exposed in the first place.

Anyway, no point in setting them unless you also build firmware that can read them.

I would recommend you bookmark the following link :wink:

.NET Micro Framework – GHI Electronics check out the library documentation section on the right side of the page.

if you are using 4.3 then a quick scan of “AddressSpace” in the library api page I found this:

so basically as of 4.3 it should be:

Edit: I updated the code on this Topic to reflect the changes between the SDKs.


I’ve added an issue on netmf github to address this to be avail thru managed code. Hopefully the team will address this in a future release … Expand available hardware information · Issue #115 · NETMF/netmf-interpreter · GitHub

@ Jay Jay - Thanks! I was searching on GHI.OSHW.Hardware, which was coming back with no hits, appreciate the assistance!