Well, may be they have stock only on US site !
The main problem today is that electronic supplier such as Digikey,Mouser, …(at least stock and other) are mostly located on one place in US and need export license. If they have stock in EU it should be easy and not need an export license. I don’t know which countries are on “exporting license” but I think it’s related to US, would really like to know how it works.
Has anyone wanted to use the BT module in promiscuous mode? I wonder if it is possible to just sniff packets.
I don’t think that’s possible with the rm186 (which has a SX1272 inside)
what you need is a SX1301 gateway frontend chip (maybe more then one 
) and some processing power
That’s a pity. Maybe with a bit of firmware hacking it might become possible. The idea is to monitor human traffic…
human traffic ? what do you mean …
Being able to tell how many people have moved through, or are in a certain location.
You can’t really do true promiscuous mode in Bluetooth LE (BLE) without a software defined radio - and a lot more computing power - because BLE uses 40 RF channels for communication. Even Bluetooth sniffers will only listen to one channel at a time.
You can however listen to advertising packets from BLE devices in peripheral mode, count the individual MAC addresses seen and use that as a count of the number of people in the room (assuming everyone has a BLE device actively advertising).
You can do the above with the RM186, for example with some simple modification of the BLE code I posted:
Just count the unique periphAddr$ returned by BleScanGetAdvReport()
Be aware that for privacy reasons some BLE devices use a private address which keeps changing so you might overcount it. Check the Bluetooth Core specification for details.
2 Likes
exactly 
About to start some expiriments with BLE 4.0 with the rm186, I’m a novice on this subject so its more study.
End goal however is to communicate over BLE with a node (settings/logfile/status ect on location)
Allready found out that its not that simple 
not all BLE devices can connect.
To ‘see’ something I bought a BLE sniffer
I cant imagine the PHY of the sniffer to be far from a BL6XX / RM186 and by extension the SX1301. … I don’t think you would need too much processing power unless you are trying to count 100’s of humans.
I mentioned sx1301 because I was thinking that you want to ‘intercept’ lora packets, but you want to count people with use of their BT activated phones… right ?
Should have specified I’m referring to the BT portion of the RM1xxJust roughly. But yes, it doesn’t even need to be 100% accurate.
Exactly like that 
Better to use WiFi (or GSM) scanning for that as most phones aren’t actively advertising on Bluetooth LE.
Not only that but without some very complex filtering one person with modern Bluetooth headphones, wearables like FitBits or smart watches would be counted as 2 or 3 persons so your data would very inaccurate.
Anybody tried to program this module with something more sane than BASIC? According specs it looks like combo nRF51822 with SX1276 over SPI. There is SWD interface on module so you can flash your own code with mBED for example (C++). You will probably invalidate certification, tough, since you need to implement LoRaWAN stack on your own (there are some on mBED) but depends on your use case.
I just think … ’ why’ ? 
Well, many drivers for various sensors have already implementation in C/C++ (in mbed, or arduino). Not reinventing wheel saves some time.
true … but ’ you will invalidate certification’ , the same for the semtech rn2483 btw.
I think you will see some (basic) libraries converted in the near future.
I think “not reinventing the wheel” goes both ways, if you use smartBASIC you’ll need new code for your sensors but all the communication inc LoRa BLE and peripherals, low power modes and certification is done for you.
If you go the other way maybe - e.g. if not timing critical - you can reuse your sensor code but you’ll have to setup your peripherals, handle your LoRa stack (I’m not sure even the mbed version is a direct drop in), do power management, BLE and of course lose the certification.
It all depends on what your sensor code does and also what you need from the module. Maybe you don’t need low power modes and/or BLE and that certainly makes it a bit simpler.
I’ve been tempted to “roll my own” stack mainly because smartBASIC doesn’t support everything the nRF51 can (please Laird support low power comparators!) but decided to keep my sanity instead and go with smartBASIC. Once you get past the “but it’s BASIC!” shock I find it much faster to develop at least for relatively simple nodes.
1 Like
