BLE communication

[DDPL]

Hi All,

I have a requirement to connect to some BLE IoT devices, I didn't know if anyone had done this in VFP. Did some stuff in the past with traditional Bluetooth using serial connections using the Windows RFCOMM I think from memory.

But the world is a different place with BLE at GATT etc., have tried to do some reading but there doesn't seem to be much out there any nothing that I can find for VFP, but assume that this should be achievable using the inbuilt Windows support API's.

Any help would be gratefully received.

Regards,

Darren

 

[Chris Miller]

To me Bluetooth is something that is handled on the OS level and as a result a connected device just works like it would be connected otherwiese, i.e. a bluetooth keyboard just works as any keyboard.

As you said GATT I gave it a shallow look. As far as I see the Windows API offers nothing VFP can use directly, Functionalities like listin/enumerating BLE devices to connect and use them I see in .NET assemblies only, so it seems to me you'll need to use the

https://west-wind.com/wwdotnetbridge.aspx.

Before you start there, this is just a general bridge to .net, not to peripheral devices or commmunication. So to get going you need to narrow down what of .net to use, and I think this is a good entry level sample:

https://learn.microsoft.com/en-us/s...niversal-samples/deviceenumerationandpairing/

It "only" covers the device enumeration and pairing, not the topic of how then to request or receive data from the BLE device.

I think the topic overall needs more to know than can be fit into a forum thread, there are whole books about BLE and GATT, for example I found "Bluetooth Low Energy: The Developer's Handbook" from Prentice Hall. Not that this must be the best book. I bet BLE and Gatt my only be one chapter of it and not give enough insight on programming this. Something from Microsoft Press would likely better get to the details in C# or VB.net and then the .net bridge would allow you to use that.

The other aspect I found is that depending on what devices you want to control, they could also broadcast their data in some way, or they pair with a smartphone, in which an app samples data and you could finally get at it on the level of already recorded data in files. For exammple I find BLE devices could be a heart rate monitor of MedRes devices, so it relates to Jan Flikweerts recent thread184-182831, in which you'll see even this has a steep learning curve or hurdle to take, as there are no universal globally used file formats.

I assume you rather want the more direct usage and record data from BLE devices yourself, which points back to using .net for this. I look forward to others contributing, but to me that's not a thing I'll deep dive myself. Surely not right now and I also don't foresee a need for myself, but good luck, I hope these pointers help you look further, i.e. finding a good book about that, or a library you could then use. I am already pretty sure, though, it's more complex than just serial port addressing.

From what I read about GATT is that those BLE devices offer a service/server you connect to and either make requests to or subscribe to broadcasts. It'll be very simple data packages starting at single integers as values, up to small structs, so very low level, not as complex like a httpresponse. So in the end this will be quite simplistic once you get to the level of getting at the data and are connected.

Edit: Do yourself a favor and specify which specific BLE device you'll need to connect and commmunicate with. Don't expect this to be as universal and simple as having a byte buffer that you read out at specific baud rate. Knowing the exact device will be key to get information about it and what it actually servees or whether it broadcasts its measurements, for example. So that's already deiding between two very different modes of operation.

Chriss

 

[DDPL]

Hi Chris,

Thank you for your reply and pointers.

I have one of the BLE IoT devices that I want to use, it is based on the Renesas chips set,

http://www.renesas.com/us/en/products/wireless-connectivity/bluetooth-low-energy.

BLE is a massive jump from traditional Bluetooth where it was just simple communications, if I look at the Bluetooth connection in Device Manager on my laptop it shows it as an RFCOMM TDI device, so connection would be simple as do that a lot with FDTI direct connected USB devices using MSCOMM for serial data exchange.

If I scan for BT devices using my laptop it only finds things like my phone in pairing mode, but it does not pick up the BLE IoT device, but there is a utility on the Renesas website that allows scanning and connection through a simple Windows app, so it must be possible, but agree it is look like it will probably need to done through .NET framework, but was given some hope that it may have been possible through the TDI even if the device needed to be pre-paired to the laptop.

Will have a read through the links you suggest, did a fair amount of reading before posting here so may have to have a mince pie and come back at it refreshed.

Thanks again,

Darren

 

[Chris Miller]

BLE is a massive jump from traditional Bluetooth where it was just simple communications

Well, what I found is that the BLE platform is a subset of Bluetooth 4.0, quote:

https://learn.adafruit.com/introduction-to-bluetooth-low-energy/introduction[/URL]]BLE ... is a light-weight subset of classic Bluetooth and was introduced as part of the Bluetooth 4.0 core specification. While there is some overlap with classic Bluetooth. BLE actually has a completely different lineage and was started by Nokia as an in-house project called 'Wibree' before being adopted by the Bluetooth SIG.

Which I interpret as saying it's something else than the usual Bluetooth as it was just adopted into the family but wasn't a core development of the Bluetooth group.

So I'd say it's a step back after a step forward. But it requires a newer Windows. The step backward is appropriate for the low level rquirements of exchanging small data structures, as far as I understand it. There has to be some drawback when it is capable to be used with low energy restrictions, it has to be simpler.

I wonder whether your notebook is Windows 10, then and has the latest drivers and a Bluetooth 4.0 compatible hardware that can find and enumerate such devics, too. Often enough, I agree, this requirtes something from the vendor on top of what Windows itself offers. To be able to address BLE you also need to have the Windows 10 Creators Update not included in the stnadard .NET framework libraries. It's a pretty new standard, and that's also just for programmatic enumeration, I didn't find something about manual pairing, I think this is not foreseen for such devices or chipsets.

The page you refer to lists about 20 products, you could become more specific than that, but alas. I think when you dived a bit deeper yourself we may step forward on how to tackle that in VFP. The technical possibilities exist, by the way with or without the .net bridge from Rick Strahl, .NET still has the foot in the area of OLE/COM to make components or properties COM visible, so they can be seen from VFP using an OLE/COM class, just not one registered by the classic regsvr32 but by a variant for assemblies regasm. Or by installers of the .NET project you'd probably need to have an assembly that's usable from VFP and can use the .net functionallity for BLE devices and GATT profiles. I don't think you'll get there completely independent from .net components, that's the core for anything, as we also already noticed not long about about topics like webcams or other devices you don't mainly address with older interfaces like TWAIN anymore.

Regarding to use a BLE device as if it was just a COM port, I can't tell definitely, but I doubt that's how GATT works, from what I read about GAP protocol and server/client architecture, this is more complex than a communication port rerad/write of a buffer existing at some RAM memory address, which works serverless. A'nd I've done COM port programming myself.

Bluetooth itself aölways only was a way to pair devices top me, with no need to understand the internal details of how the actual blueetooth communication is established and works, you just have a new output audio channel or input (mic) with a bluetooth headset, you have a bluetooth keyboard that works completely the same within VFP as any keyboard input, you have a bluetooth mouse that also just setss the systems mouse pointer position and mouse keys, nothing that needs any VFP side specific programming. But you seem to have experience with a chipset that offers serial COM communication over bluetooth. It's not opening up the norm of bluetooth, that's just COM hooked on bluetooth. Just like there are many chipsets enabling to use COM via USB, that also doesn't mean you program the USB serial port, now, you just get COM port behavior usable with the legacy components also available to VFP, like the MSCOMM OCX, which are hooked and actually work via USB protocol behind the scenes, or bluetooth. But that's not how Bluetooth itself works, or GAP or GATT.

Chriss

 

[DDPL]

Have been playing a little, but need to correct something that I stated earlier.

Notebook is Win 11, when you go into Bluetooth & devices you turn on Bluetooth and then press the 'Add device' button and it searches for nearby BT devices, and comes up with my phone etc.
A little bit further down the page there is an option 'Bluetooth devices discovery' if you change this from 'Default' to 'Advanced' and then do a 'Add devices' it then finds the IoT device.

If you then request to connect the LED on the device immediately starts flashing blue to indicate that a connection has been made, then after about 30 seconds stops and Windows tells you that you should try connecting again. The Renesas device that is being used in the DA14531MOD.

I have a C# guy having a look at it for me, I am not blessed with anything that modern in my toolkit but haven't found much I couldn't do in VFP over the years, and even if via

http://wwwdotnetbridge

(thank you for that one will have a proper look) there should be a way.

 

[Chris Miller]

That's still not a specific product but a chipset that aims to be used in many future IoT devices, according to

https://www.renesas.com/us/en/produ...d-smartbond-tiny-bluetooth-low-energy-module.

Quote:

If you scroll down a bit you see under Software & Tools that it provides/includes a Serial Port Service (Emulator), which means it emulates being a COM Port. So I guess you could reuse the code you already have.

The data sheet of that also sounds like that...

https://www.renesas.com/us/en/document/dst/da14531-module-datasheet?r=1601921[/URL]]The module comes with a configurable DSPS (serial port service) and next generation Codeless
software to design Bluetooth® applications without Bluetooth® knowledge or advanced programming skills.

In short, it's programmable just like there was a physical COM port. My opinion of that is that they think along wrong lines if they mean that to be simpler, I mean legacy knowledge is becoming extinct and serial port programming therefore is a backwards skill just as hard to find as advanced programming skills. But that's just opinion, of course.


True to say there are a lot COM related libraries out that therefore can be used with that. However that doesn't tell which AT commands are used with that, for example.

To be very clear, I also won't expect Renesas to specify that, they want their module to be universally usable for any kind of IoT devices, but there will also be a different commandsets or protocols these devices can use within how serial port communication works with basic features like baudrate and parity bits, etc.

For now it means you could reuse some serial port code you already have, but what exactly to write or send and read or receive will be specific to the concrete end user product that will have that chipset besides anything else part of that IoT hardware.

Chriss

PS: Just one more note about this Serial Port Service (Emulator). Before you get to this and can address this module like it is a serial port, you still have to first go through the stages of finding the device and connecting to it, and without more specific documentation about available serial port addresses, baudrates and all the other things related to serial port communication, you still have no grip on this emulated serial port.

My comment on this: I'll not predict them to fail, they might just rule the market of communication modules used in BLE IoT devices by their price, but there are reasons, features serial port communication lacked, that lead to the development of USB replacing serial ports. I had the ridiculous case of a device defining a command to send to it, which in response gave you the baudrat and parity etc on which the device was set. But for the device to understand this command and respond to it with this information you need to estsablish the serial port communication, you had to know the baudrate parity, etc to set up, otherwise this command was not received or not recognized and you got no response. That has forever determined what I think about serial port communication.

If you ask me how an interface with any device should be designed: That will depend on the device, if it is a video camera (like a dashcam, for example) with this bluetooth module I'd expect it to offer a driver with which I can get a videostream of a framebuffer, define video resolution and framerate, maybe it would even show up as a drive letter and I can simply get mp4 files from that. But I'd not want a COM port to program the details of getting data from the device. In some cases of devices it might fit well to have that low level access, but in other cases not at all.