Receiving iBeacon in VB6

First let me say how thankful I am for this forum! I don't post often but have been reading it every day for years.

Working with a device that sends an iBeacon with information every 5 minutes. I'm needing to create a program that receives the information and then I can process it. The manufacture has supplied to me what each of the bytes in the iBeacon are I just need to come up with a way to receive them.

I tested setting up a virtual COM port for the Bluetooth and then used the MSCOMM control but nothing is received. Thinking it's because it's not a device that is paired with Windows. These devices do not pair - only send out the iBeacon.

I've read a lot about iBeacon and what it sends but have not been able to figure out a way to receive these in VB6.

Has anyone attempted this / has any sample code to receive these?

Thanks!

Quote:

---

Originally Posted by Kevin2

. . . but have not been able to figure out a way to receive these in VB6.

---

Do you have some sample code how to receive these *not* in VB6 e.g. in C# or something else?

cheers,
</wqw>

Quote:

---

Originally Posted by wqweto

Do you have some sample code how to receive these *not* in VB6 e.g. in C# or something else?

cheers,
</wqw>

---

Thanks wqweto!

Some of the information I have found makes it sound like iBeacon is just BLE with a different header but not sure if that is true.

I've found a few samples but not much - this one seemed to have the most information:
https://www.hackster.io/ryo-naka/dis...5mtickc-483b28

The device I'm working with sends some basic temperature information as well as a few other things in it's iBeacon.

There are some WinRT classes in Win10: BluetoothLEAdvertisementWatcherTrigger Class, BluetoothLEAdvertisementPublisherTrigger Class

Working with WinRT classes in VB6 is non-trivial.

cheers,
</wqw>

I think your issue is the use of a "virtual bluetooth com port", which is intended to act as a "direct wired device", to a "bluetooth paired device". The "pairing part" is critical.

If you are linking the signal to a com-port, then it is your job to program the "send" signal that asks nearby devices for a ping, as well as decoding that raw com-data, to get the names and ID's and "gimme a pin" responses.

Also, Do you even have bluetooth on your computer? It has to be the correct one for the device. Unlike a phone, which may have multiple bluetooth formats available for connecting, a computer's dongle or internal blue-tooth is usually specific to ONE type of bluetooth signal and "code format". Just like you can't use "any wifi connection" on A, B, G, etc... unless it is A/B/G, or just ONE of those. (this is not like logitec's Bluetooth mouse, which is A Bluetooth signal, just not one normal Bluetooth can talk to. I was unsure if it was THAT specific)

The first step will be either a "stateless pairing" (usually code 0,0,0,0 or null,null,null,null or just an echo of the broadcast devices "ID" or "NAME") If it requires pairing, which it seems to require, otherwise it couldn't be "secure", and it says that ONLY xxx device can communicate with it, which requires some kind of pairing or token credentials, even if it is a slip of paper with a code or a pin on a device...

Once paired, the data-stream will be open to "listen" for requests, other than "provide proof that you are MY OWNER". It will also produce a response data-stream, which is the "bits" that they sent you the info for, to decode, but only if you ask for it. It will not usually just start spewing out data for someone to intercept. I hope...

Quote:

---

Originally Posted by ISAWHIM

I think your issue is the use of a "virtual bluetooth com port", which is intended to act as a "direct wired device", to a "bluetooth paired device". The "pairing part" is critical.

If you are linking the signal to a com-port, then it is your job to program the "send" signal that asks nearby devices for a ping, as well as decoding that raw com-data, to get the names and ID's and "gimme a pin" responses.

Also, Do you even have bluetooth on your computer? It has to be the correct one for the device. Unlike a phone, which may have multiple bluetooth formats available for connecting, a computer's dongle or internal blue-tooth is usually specific to ONE type of bluetooth signal and "code format". Just like you can't use "any wifi connection" on A, B, G, etc... unless it is A/B/G, or just ONE of those. (this is not like logitec's Bluetooth mouse, which is A Bluetooth signal, just not one normal Bluetooth can talk to. I was unsure if it was THAT specific)

The first step will be either a "stateless pairing" (usually code 0,0,0,0 or null,null,null,null or just an echo of the broadcast devices "ID" or "NAME") If it requires pairing, which it seems to require, otherwise it couldn't be "secure", and it says that ONLY xxx device can communicate with it, which requires some kind of pairing or token credentials, even if it is a slip of paper with a code or a pin on a device...

Once paired, the data-stream will be open to "listen" for requests, other than "provide proof that you are MY OWNER". It will also produce a response data-stream, which is the "bits" that they sent you the info for, to decode, but only if you ask for it. It will not usually just start spewing out data for someone to intercept. I hope...

---

Thanks for the reply ISAWHIM.

I do have a compatible Bluetooth adapter in the laptop I'm testing with. The device uses BLE and does not have an option to pair. I didn't think a virtual COM port would work but tried anyway to make sure. The device simply sends out an iBeacon every 5 minutes. The device uses an ESP32. Here is a basic description of that https://esphome.io/components/esp32_ble_beacon.html

This is sounding like it's going to be very difficult in VB6 :(

Kevin

Quote:

---

Originally Posted by wqweto

Working with WinRT classes in VB6 is non-trivial.

---

I wouldn't say so. Once you understand the WinRT classes and interfaces, it's pretty easy. I've written various WinRT examples with VB6 and many things are repeated in different classes/interfaces.

Sounds like you need an ESP32 IO, talking to the COM port... If you get bluetooth->Com... there may be a library for esp32, for com, which you need, for VB6, as the COM communications.

Are you using API or the old MSCOMM OCX for COM(serial port)?

Maybe this post will help. You will not get a reply back if it isn't talking in a certain period of time. You would have to poll it, over and over, until you get a response.
https://www.vbforums.com/showthread....uetooth-device

There was mention of other blue-tooth/com issues related to detecting bluetooth devices on com(serial) ports. (Not sure about emulation though.)

Do you see the device on your phone if you scan for new devices? (Is it coming and going, depending on if it is in a "broadcast period window")

Last time I used communications like this was when I was programming arduino chips on an RS232 emulator USB connection, and manually talking to LPT1 printer port for my DIY CNC machine servo-drivers.

If the beacon does not require pairing maybe an sdr would work?

I don't think that the BLE support introduced in Windows 10 1703 is available to a VB6 program. The gyrations required to make a native desktop application able to use WinRT/Metro/UWP APIs are a pretty high wall even for C++ programming.

When I was looking into this a few years back I opted instead for an Ethernet TCP/IP to BLE 5.0 bridge ("Manager") device from a company named "Jinou."

There was no Windows API library, you had to use a Winsock control and TCP/IP to talk to the bridge. The documentation was very low level, basically giving the various "Data Packet" descriptions and some general usage guidelines.

I never got very far and dropped the effort.

Quote:

---

Originally Posted by Kevin2

The device simply sends out an iBeacon every 5 minutes.
The device uses an ESP32.

---

If the iBeacon is sent by an ESP32,
then a second ESP32 (programmed by you, acting like a Proxy) -
should be able to receive (decode and translate) that signal...
(then passing the decoded payload, via Rs232/USB or via WLAN to your Desktop-App).

Olaf

Quote:

---

Originally Posted by Schmidt

If the iBeacon is sent by an ESP32,
then a second ESP32 (programmed by you, acting like a Proxy) -
should be able to receive (decode and translate) that signal...
(then passing the decoded payload, via Rs232/USB or via WLAN to your Desktop-App).

Olaf

---

Thanks Olaf - that's actually the reason for writing this program is to eliminate an in between device. Currently the device connects to an android or IOS device and then it passes on the beacons.

Quote:

---

Originally Posted by Kevin2

Thanks Olaf - that's actually the reason for writing this program is to eliminate an in between device. Currently the device connects to an android or IOS device and then it passes on the beacons.

---

I can't see larger problems with such an "in-between-device".
- an iOS-tablet or -phone receives the "beacon-messages" directly via bluetooth
- an Android-tablet or -phone receives the "beacon-messages" directly via bluetooth
- your "VB6-driven" Desktop-PC or Notebook will receive the beacon-messages e.g. via WLAN
..(from that little "ESP32-based intermediate-device", which costs $3 and acts proxy-like as a translator)

In that latter case no "physical connections" to that intermediate-device are needed (no cables or plugs).
(and the WLAN-range of that device should be much higher than the bluetooth-range).

The only problem I see, where this approach could be "in-desirable" is,
when there's "multiple beacon-sending devices, scattered over a wide-range" (in a "positioning-related scenario") -
(in that case you'd have to take the little device along with your Notebook of course, somewhere in your pocket).

Olaf

Quote:

---

Originally Posted by Schmidt

I can't see larger problems with such an "in-between-device".
- an iOS-tablet or -phone receives the "beacon-messages" directly via bluetooth
- an Android-tablet or -phone receives the "beacon-messages" directly via bluetooth
- your "VB6-driven" Desktop-PC or Notebook will receive the beacon-messages e.g. via WLAN
..(from that little "ESP32-based intermediate-device", which costs $3 and acts proxy-like as a translator)

In that latter case no "physical connections" to that intermediate-device are needed (no cables or plugs).
(and the WLAN-range of that device should be much higher than the bluetooth-range).

The only problem I see, where this approach could be "in-desirable" is,
when there's "multiple beacon-sending devices, scattered over a wide-range" (in a "positioning-related scenario") -
(in that case you'd have to take the little device along with your Notebook of course, somewhere in your pocket).

Olaf

---

Thanks Olaf - there is a solution available like what you described and that or an android/ios device is what is currently used to grab the ibeacons and then that device is forwarding the information by WiFi - this is all functional already. Can be upwards of 10 devices that the ibeacons need to be received from at an interval of 5 to 15 minutes. Trying to do this so it's all contained within the same program that reports the information rather than having to rely on the android/ios/ESP-relay relaying the information to the program.