Central role: Initiates connection, scans for advertisement packets
Peripheral role: Advertises, accepts connection requests
Client: Sends read and write requests to remote device, receives notifications, generally associated with the Central connection role.
Server: Holds data locally (database), sends notifications based on settings and data, responds/accepts/rejects read/write requests based on data.
Since you are wanting all of the devices to:
1. Be symmetrical
2. Both advertise and connect
You will need to setup the "image" to hae both Central and Peripheral roles selected;
Since you are wanting to both send and receive data, you will probably want both data roles to be used as well (Client, Server).
Data serving done through the BLE component setup is easy to setup as a constant size, but would take some work to make dynamically sized/allocated data. Since you will be using all roles, it will be pretty complicated :)
(There is callback functionality for data access through the BLE protocol, but I haven't played with it)
For the 100 projects in 100 days, depending on your knowledge of the cypress chips and BLE protocol, I would start with examples that specifically isolate those components that you want to know, and then expand from there.
Keep in mind, that the BLE standard services and the custom services are slightly different in implementation and handling, but technically do the same things.
This sounds like an interesting project, but I'm curious why the devices would exchange bundles that are fixed, and have a fixed number? Since, you are controlling all the devices, I would assume you could just tell the code what/how much data you have.
Unless you are doing a self-discovery network, in which case it looks cool :)
Many of the examples are setup to demonstrate specific applications, but they do use the underlying mechanics in the implementation, and thus display how you would do something similar using the code and chips.
If you know BLE, I would start with:
If you don't:
Thanks e.pratt. These look like some great avenues to pursue. I’ve been playing with the Mesh Flood and Client/Server examples. I have two to the CY8CKIT-042-BLE Pioneer Kits and also four EZ-BLE PSoC Evaluation Boards. On one of my Pioneer Baseboards, I can’t get the RS232 input line to work. Appears to be shorted on the board (intermitantly). The other one works. Hard to get the Client/Server example to work without that. That Mesh Flood example only transfers the LED color to other nodes that are currently in the piconet. As new devices join, I’m trying to figure out a way get them to sync.
What I’m trying to do is use these BLE devices in automobiles to automate the scoring of Time-Speed-Distance (TSD) car rallies. The objective of a TSD Car Rally is to follow a (sometimes cryptic) public road course, travel at exactly the prescribed average speed, and get timed at points along the course unknown to the contestants in advance. The best scores are those with the lowest total error at those points. I have a method of self-timing the cars as they pass along the course (not part of my question here). As these devices collect their timed data, I would like to pass that data along to the devices in the other cars. It is desired to keep track of the cars periodically during the rally as we send a car through afterward and look for cars that are lost (or crashed – hey – it happens). This transfer only needs to be done when the cars are parked next to each other (maybe 50 feet/15 meters). Each cars device will have the most up-to-date timing information for itself. But I would also like it to store the timing information for the other cars and pass it along in a sort of “mesh” network. In short order, all devices should synchronize all of their timing data.
I'm assuming you don't actually mean RS-232 exactly, as that runs at 10s of volts for the specification of RS-232 :)
Sometimes those UART connections/cables are finnicky, so you could try different cables or see if you can get a better connection in some way.
Interesting idea for timing contestants. Sounds pretty clever to me.
Ideally, you would want to set a maximum number of car-data packets that the device will hold, otherwise you have to deal with dynamic memory allocation (which is a pain). In order to make sure the cars are synchronized, you will need to figure out what you want to do if you get mismatching values between chips (a "master" for each data packet, and the rest are "slaves" that will update their value from the master one).
If you have the devices resyncing with ALL other devices in the piconet, regardless of whether they last had accurate data or not, then it will recheck devices that have newly joined the net as well. You could also have a specific "nodelist" packet that tells the units the list of nodes on the net (with some way to clear them I'm assuming), and when a new node joins it merely presents a "nodelist" that has its own address in it to another node. Then that node will propagate it along when it updates with another device. This would eat bandwidth to have them all rechecking each other, but it would allow dynamic changes once they are already set :)
The other option is to have some sort of method that the chip runs upon connection to the meshnet that grabs the synced data from the other units, allowing for dynamic changes (which are already working) to be fine, and the newly joined units to receive the "static" data from before they joined with an "initialization" method of some sort.
e_pratt, I mis-wrote. It is not an RS232 signal. It is a 3.3V serial data from an FTDI serial/USB module. I think this Dev Board setup shares the TX-IN signal with the CapSense. There is a 500 ohm something their but sometimes it is shorted. No worries. I have four more of those Pioneer Baseboards on order. Serial output works pretty well for debugging though.
I plan to limit the total number of competitors. Each car will have complete timing data for itself. I may have the other cars request just the missing (newer) data for the other car or re-send the entire set. Probably each car will broadcast its total number of checkpoint event. Then alternate with broadcasts for the data it has acquired from other cars. Also some kind of checksum, CRC, or MD5 for validity checking. Other cars can check their list for a car and request an update.
Yeah, serial output is nice to debug :)
What you are describing sounds pretty feasible/well-thought out to me; It might be rough to write the code to handle all of those functions in a timely fashion, but kudos for that. I would suggest planning out arrays' data that you need each car to be sending/receiving from the others, and setup methods to update just the parts that need it (checking them with either a CRC, MD5, checksum). The BLE link might already be doing data integrity at the lower levels, so it might be worth testing to see if you even need your own validation method.