OK, makes perfect sense now. Good to hear you got it working. I've done my share of head scratching with the uint8array, too. 

Can you post the code that you use to process the scan reports? I doubt that the bug is in the stack.

For an example of how to scan through the AD elements in an advertisement packet, see for example the SPP example and the file spp_client.c / function process_scan_response()

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/13/spp-over-ble_c_examp-mnoe

The first half of MAC is company identifier (e.g. 00:0B:57 for Silabs) and the second half is a unique number (in the scope of that company identifier).

I would say that if you take the LSB of the company ID and the 2nd half of the MAC to be used as your identifier, then the chance of getting two overlapping IDs is zero.

For example, you have Silabs chip with MAC 00:0B:57:00:00:01 => 32-bit unique ID = "57:00:00:01".

At some point, Silabs will need to start using a new company identifier (it is actually done already, there are several company identifiers owned by silabs).  

The only case when there would be potential issues is if Silabs takes a new company identifier into use AND the LSB of this new identifier is the same as in some older version. For example, if the new company ID would be 01:0B:57 then there's a chance of conflict. However, the chance of this happening is close to zero.

EDIT: seems like I was making bad assumptions. When looking up the Silabs indentifiers, there are actually two OUIs used by Silabs that share the same LSB:

https://aruljohn.com/mac/vendor/silicon%20laboratories

Also, the terminology in my response is all over the place, the correct term for the first half of MAC is OUI (Organizationally Unique Identifier.) 

In the end, however, I would still claim that the chance of having overlapping unique identifiers is very, very small.

The first half of MAC is company identifier (e.g. 00:0B:57 for Silabs) and the second half is a unique number (in the scope of that company identifier).

I would say that if you take the LSB of the company ID and the 2nd half of the MAC to be used as your identifier, then the chance of getting two overlapping IDs is zero.

For example, you have Silabs chip with MAC 00:0B:57:00:00:01 => 32-bit unique ID = "57:00:00:01".

At some point, Silabs will need to start using a new company identifier (it is actually done already, there are several company identifiers owned by silabs).  

The only case when there would be potential issues is if Silabs takes a new company identifier into use AND the LSB of this new identifier is the same as in some older version. For example, if the new company ID would be 01:0B:57 then there's a chance of conflict. However, the chance of this happening is close to zero.

EDIT: seems like I was making bad assumptions. When looking up the Silabs indentifiers, there are actually two OUIs used by Silabs that share the same LSB:

https://aruljohn.com/mac/vendor/silicon%20laboratories

Also, the termonology in my response is all over the place, the correct term for the first half of MAC is OUI (Organizationally Unique Identifier.) 

In the end, however, I would still claim that the chance of having overlapping unique identifiers is very, very small.

The first half of MAC is company identifier (e.g. 00:0B:57 for Silabs) and the second half is a unique number (in the scope of that company identifier).

I would say that if you take the LSB of the company ID and the 2nd half of the MAC to be used as your identifier, then the chance of getting two overlapping IDs is zero.

For example, you have Silabs chip with MAC 00:0B:57:00:00:01 => 32-bit unique ID = "57:00:00:01".

At some point, Silabs will need to start using a new company identifier (it is actually done already, there are several company identifiers owned by silabs).  

The only case when there would be potential issues is if Silabs takes a new company identifier into use AND the LSB of this new identifier is the same as in some older version. For example, if the new company ID would be 01:0B:57 then there's a chance of conflict. However, the chance of this happening is close to zero.

EDIT: seems like I was making bad assumptions. When looking up the Silabs indentifiers, there are actually two OUIs used by Silabs that share the same LSB:

https://aruljohn.com/mac/vendor/silicon%20laboratories

Also, the termonilogy above is all over the place, the correct term for the first half of MAC is OUI (Organizationally Unique Identifier.) 

In the end, however, I would still claim that the chance of having overlapping unique identifiers is very, very small.

The first half of MAC is company identifier (e.g. 00:0B:57 for Silabs) and the second half is a unique number (in the scope of that company identifier).

I would say that if you take the LSB of the company ID and the 2nd half of the MAC to be used as your identifier, then the chance of getting two overlapping IDs is zero.

For example, you have Silabs chip with MAC 00:0B:57:00:00:01 => 32-bit unique ID = "57:00:00:01".

At some point, Silabs will need to start using a new company identifier (it is actually done already, there are several company identifiers owned by silabs).  

The only case when there would be potential issues is if Silabs takes a new company identifier into use AND the LSB of this new identifier is the same as in some older version. For example, if the new company ID would be 01:0B:57 then there's a chance of conflict. However, the chance of this happening is close to zero.

Does it need to be sequential? Each EF32BG chip has a unique 64-bit number that is burned in production of the chip. It is not sequential but it is unique. 

In your production line, you can check the unique ID of each device for inventory purposes. 

If you really need to write a sequential number to each produced device then it should be not a big task, there are many ways to handle that. One option would be to just write it to some fixed location in the User Data page in flash. Search for User Data page in the ref.manual and you'll find more details. There's also some useful forum posts you can find with the same keyword.

See chapter 2 in https://www.silabs.com/documents/public/user-guides/ug118-bluegecko-bt-profile-toolkit.pdf 

12 is way below the maximum limit.

doesnt hit on bg_lib in MCU

No idea what you mean by this. 

I have used BLED112 in some of my own scanning tests that have lasted several days in a row, capturing data from number of sensors. When I processed the data afterwards I did not notice any gaps. This was a test setup where I had 4 sensors transmitting a packet once per second.

One key difference compared to your setup is that I used 100% scan duty cycle.