Take a look at the PSOC roadmap document, it does a pretty good job of showing the differences between the CY8C4247... series parts and the CY8C4127... series parts. You'll see that there are significant differences in the amount of RAM, and FLASH which affect the capacity to store a given complexity of an application program. There are also other differences with respect to the number and type of integrated peripheral hardware units, but in your case you really don't need any of the "extra" peripherals in the higher functionality parts. You need bluetooth itself to work. You need the RAM and FLASH sufficient to run the Bluetooth code and other library functions your program will integrate from the Cypress firmware library. You need to make a beep and not much more than a GPIO and maybe a timer is needed to do that along with a speaker and speaker driver. You need a power supply circuit of some kind to connect the battery to the battery powered unit(s) which might just be a direct connection to a cell or it might involve a regulator or charging circuit or something depending on your design needs.
Anyway it sounds like the simple answer is that you could use ANY of the PSOC or PROC BLE parts which have enough RAM/FLASH. I assume that with a relatively simple application like yours that perhaps even the smallest offered RAM/FLASH may be more than sufficient to handle your application, but it may be getting a bit tight on the smaller capacity parts I suppose.
The other aspect to the choice is that not all models of the parts are now in production or at least are now available for off the shelf purchase. So depending on the lead time by which you need development and production quantities you may choose a more immediately available part or perhaps they'll all be ready soon enough for you.
The smallest package type is the FNI chip scale package, and the LQI QFN package is a bit larger but still is only 7mm by 7mm.
So your "best" choice is the least expensive most adequately available PSOC or PROC part, preferably in the FNI package for the small unit, but the LQI option may suffice for you. The FNI package probably requires more layers or more fine engineering of the PCB due to its small pad geometry, whereas the LQI package can easily be implemented in a low cost 2 layer PCB.
Since the parts are almost identical except for peripherals you don't need you might as well just build your application with two of the PSOC or PROC modules from the BLE development kit that is available today and then you can test the functionality as well as determine exactly how much RAM and FLASH you need. Once you are sure about the RAM and FLASH you will know exactly what the least capacity lowest cost part you could use will be since the bluetooth performance will be comparable for all of them. The exact PCB layout and antenna and enclosure implementation will affect the loss and transmitted power by a few dB but it should not really matter much for your short range application in which case the less the RF efficiency the higher your power consumption may be to compensate for it but it should be really pretty reasonable even with 9dB higher loss than the development kit modules.
The CY8C4127 series parts are lower capacity and will be expected to be less expensive than the CY824247 parts, and within each group there are six or so options for different package types and RAM/FLASH/peripheral capacities, so there will be some price overlap maybe between the high and low end of the two series.
I would look at the CY8C4127LQI-BL473 or the CY8C4247LQI-BL473 since it looks like they're relatively inexpensive at budgetary prices and might be among the "initial release" parts (I'm not sure, check the roadmap and sales). Or see about the FNI package for smaller size if that will also be available and affordable soon.
They should all work basically interchangably in your software and only vary according to the LQI or FNI pinout in hardware. The rest of the differences are just performance and extra peripherals.
Check the PROC pricing and availability also since maybe it will better, I don't know so much about that pricing and availability line-up but again the features are still exactly compatible with your needs for PROC or PSOC as far as I can tell.
Here's the roadmap document:
Here's the product brief:
And it turns out that for the fine details of the differences between the parts ordering codes you need to look at the table a couple of pages before the end of the datasheet which is here (check the "Ordering Information" on page 36):
PROC data sheet:
PROC Product selector guide:
PSOC BLE selector guide:
Looks like with the PROC they also call the packages FN vs. LQ for the CSP small one and QFN larger one respectively. The "I" I mentioned above (in LQI vs. FNI) is not part of the package type code so it is the same LQ/FN code for PROC or PSOC BLE.
Welcome in the forum, Mike!
Best advice I can give you is to get hands on a development kit for BLE www.cypress.com/ You can get a feeling for the possible sizes and build a prototype.
What I cannot see yet is how you will detect the distance between your server and the client.
Well you can't use Bluetooth's integrated abilities with the PROC/PSOC BLE to easily "directly" measure the distance between a node and another node since that would involve doing something like a delay compensated time of flight measurement or phase correlation or something that is not so practically possible.
But "standard" BLE 4 can incorporate the "proximity profile" and similar methods which use the received signal strength measurement value at a node as an analog of "distance" between the node and some other node simply because the signal will be maximum at nearly zero distance and will decrease with increasing range.
Objects nearby or in the path that reflect or absorb / attenuate the signal will cause some complications with the proportionality of correlation of RSSI to "distance" but over relatively short distances and relatively unobstructed RF paths it can "work" well enough to have a sense of if your peer node is still "near" (strong signal) or is "far" (weak signal) or "gone".
Awesome thanks guys,
I will have a look at the product mentioned and see what i can work out.
For the distance issue: I was thinking i might be able to use the signal strength or DB to trigger when it hits below a set threshold. Not sure if that is possible but just thinking out loud.
There is a CyBle_GetRssi() API which will deliver the signal strength. When you calibrate that at time the switch is pressed you will be able to detect signal strength fading. For the switch, saving hardware costs and space needed, have a look at a CapSense solution
Are you trying to measure link distance or link quality ? If the
former signal strength would not be a usable measurement
unless your application were in a controlled repeatable environment.
For the distance measurement, you cannot rely on the RSSI parameter if your end application is meant for indoor usage.vI have seen sudden drops in RSSI at certain spots. This could be because of multipath fading, phase mismatch, etc. Also, if your antenna is directional (even partly), the RSSI will change with the antenna orientation at the same physical spot.