Cypress BLE sensor beacon with Bluz GWS


#1

Hello Folks,
I have two Photon devices currently hard wired to a number of sensors; mainly environment data.
The wiring is getting out of control and I want to switch to BLE sensors.
I thought the logical direction was to use a Bluz gateway shield, but it seems it is strictly designed to talk to Bluz DKs.
While I could use a DK, I think it is too powerful and physically big for what I need.

I have searched other posts both on the Photon and the Bluz side and I was not able to find a solution to what I am
trying to do; at least not in enough details for me to implement directly.
Most solutions deal with phone or tablet apps, but I am using the Photons.
I found a post about the Bluz Coin, but it seems that it is not a real product (yet?).

I really like this device from Cypress that requires no battery: BLE temperature sensor beacon
Can anyone tell me if the GWS will recognize this beacon and gather the sensor data? There is plenty of documentation for this sensor, but I don’t know what is relevant.

I might get away with one Photon+GWS to read all the sensors (5 for now), but I am thinking of adding other tasks that would require more I/O pins. I may need to add a second Photon+GWS. Is there an issue with more than one central
BLE controller? Is there a way to force each GWS to only pair to specific BLE beacons or peripherals?

I know it’s a lot to ask in one post. It seems like a logical progression for Bluz… referring to the Coin.

Thanks,
Pesc


#2

You can certainly use the gateway shield hardware, but you are correct that it would take some significant firmare changes to make it talk to other devices as it is designed for bluz. It isn’t terribly complex to do, and others have done this, but if you aren’t familiar with embedded development with C/C++, it may be a lot.

The bluz coin was definitely something we wanted to pursue, and would be open to it if we think people would want it. I hadn’t seen a strong response at the time, but it could be time to revisit if others are interested?


#3

I need to vent a bit first. This BLE standard is not so “standard”.
I can see wanting to encrypt data in some applications, but I am wondering why it’s not as simple as sending a defined string of bits that any central node can read. The more I read about BLE, the more confused I get.

Anyway… I would definetly buy 5 Coins today, if they existed… depending on price. I think the right thing to do is to switch to the Bluz Coin thread, since it has the proper title.
See you there..


#4

Sorry for your frustrations, but the BLE standard is indeed a standard. However, it provides some lower level capabilities that require further work for devices to talk to one another.

To break it down, BLE provides services and characteristics to talk from one device to another. While not a direct analogy, I generally explain these to people as similar to network sockets. The service can define what type to connect to (UDP, TCP, etc.) and the characteristic is the actual port to connect to (80, 22, etc). This is a simplification, just trying to explain.

So, bluz defines some set of services and characteristics to talk to, they are documented in our source code. Our hardware (DK and gateways) is setup to handle to those services and characteristics so we have an ecosystem for bluz. Then we add an application layer on top that uses those for a specific purpose, in this case to talk to the Particle cloud. That application layer is analogous to software on your computer that uses sockets for communication, like Skype or your web browser.

So, what you end up with is different boards that talk through their own unique services and characteristics to their own application layers. I am sure those Cypress boards have an app or something else that understands their services and characteristics and does something with the data.

So, to sum it up, it takes some work to get these different devices from different ecosystems to talk to one another. We would have to understand their services and characteristics and figure out how to talk to them to make it work. It would be loosely similar to figuring out how to make Skype talk to Slack, they are different applications that use different parts of the TCP/IP stack to work.

I hope that helps, just trying to explain the difficulties in making different BLE devices talk to one another.


#5

Thanks for the analogy. It makes perfect sense.
I am trying to avoid going too deep on BLE and Bluetooth in general because I focus on the hardware design part.
However, I still need to know something about it.
This is certainly naive on my part, but I expected that for a low power architecture there would a really simple message stream: an ID and a string of data.
Using your analogy, perhaps this would be similar to opening a Telnet session between two completely different computers. I guess the Telnet app doesn’t exist for BLE.

Touching on the Cypress chip a bit, they publish a boat load of documentation. Can you recommend a book or a tutorial I can start with to understand what to make of all the documentation?

Thanks,
Pescatore


#6

So to help you understand Bluetooth, at least the way I understand it, let me give you a simple description. Bluetooth is ultimately different from say, a TV’s remote control infrared data transmission, because that remote’s signal could work with another device. The IR is simply a radio signal interpreted as digital, while a Bluetooth signal is a radio signal that is always a digital signal. If that makes sense… In Bluetooth, each device that talks to each other has a specific type of communication protocol. This allows networks of devices. What makes it unique is that Bluetooth can talk to all these separate entities at once without interfering with each other. Also they do not have to be in line of sight like the IR sensor.

Here’s a beginner book on Bluetooth, though I’m not familiar with Cypress.+ https://www.amazon.com/Make-Bluetooth-Projects-Raspberry-Smartphones/dp/1457187094/