I've been asked to create a system where by 100+ bar code readers are connected wirelessly to 2 or more access points (pcs). The bar code readers I've seen so far all use blue tooth as the wireless connection so I was wondering is it possible to have a set up where all 100+ bar code devices can connect to a single PC?
Its also likely that the system will be used in multiple locations so multiple hub pcs might exist in which case the bar code readers should just connect to the nearest one.
Its this a supported set up for blue tooth or would I need to look at some other way of connecting all these devices.
Related
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
I'm working on a product which is a "black box" device that will be connected to a client's network. I am looking for a method of assigning a static IP address to the device (or configuring it to use DHCP, which will likely be the default). There is no physical user interface, no screens or buttons to enter such information on the device itself. It will have a web-based interface, but to use that it will need to obtain an IP address first and the user will need to know what that address is.
I have used a number of devices similar to this that come with utility that you run on a PC which detects the device on the network and allows you to view and change its IP configuration. This is what I would like to do, but I'm not sure which protocols to use or how to go about it. I picture the utility broadcasting a "who's there?" packet over the network and my black box device responding with an "I'm here" packet. The utility would then theoretically know the device's MAC address and could communicate further by requesting its current IP configuration and sending it new configuration if needed.
Side note: The black box will be running some flavor of Linux and the utility should run on Windows.
EDIT: Typically we will ship one of these black boxes to a customer, they will unpack it and plug it into their network. Outside of communicating with it over the network there is no way to configure the black box; there is no monitor and keyboard, no user interface panel of any kind, no means of editing any configuration files in the Linux file system. The utility we provide the customer must be easy to use. They should be able to run the utility, see the device in a list of detected black boxes, and select the device to view or modify its configuration. These users are not system admins, I do not expect them to be able to connect to the black box via SSH and edit configuration files.
I welcome suggestions on approaches to take or protocols to use to accomplish my goal. If you have experience doing what I am trying to do please outline what you did (or how you would do it now).
Thanks!
This is my first question in Stackoverflow :)
I'm trying to make few modifications to the Ti Sensortag but I have few questions please:
1- is it possible to make the sensortags communicate with each-other without a gateway?
(lets Say I put Sensor1 in bedroom 1 and sensor 2 in bedroom 2 can I make them exchange readings without the need for a gateway?)
2- can I install a micro USB over the interface connector to be able to use a portable battery pack? (photo of the interface connector)
thanks
You'll get better more in depth responses on the TI support forums as Ifor has said.
However, I can tell you the answer to #1... Regular bluetooth allows for things like piconets, but Low Energy does not. With LE you have a client/server (master/slave) connection between two devices only. It may be possible to modify the firmware on the sensortags to allow them to make connections to other sensortags, but then they'd have to give up whatever connection they currently had to do so. The master devices can connect to multiple slave devices, but the slave device can only be connected to one master.
As the sensortags are currently designed, I think they only work as a slave (server) device.
Press releases say that the new 4.1 spec allows for a single BLE device to act in both roles--central and peripheral eliminating the need for a gateway. A 4.1 update is, in theory, possible with 4.0 radio hardware like the SensorTag has. I personally haven't seen an example of this however and SensorTag processing resources may be a limiting factor to a dual role.
The Battery Pack connector breaks out VDD_EXT and GND and the SensorTag hardware schematic is available. Analysis by a hardware design engineer should be able to determine the suitability of a USB source powering option.
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
I am trying to find a clever way to keep a BLE app active in the background on iOS 6, without breaking any of Apple's rules. I plan to use the phone as a peripheral device and another BLE circuit as the central. My app will automatically be opened when a user arrives to a building using geofencing. After that the iPhone will connect to the first BLE central device it sees (the device will be in its white list). The user will then be able to move throughout the building switching to different BLE "nodes".
My question is: What do I need to do in the background when a user is stationary at their desk so that the app does not get suspended due to memory resources?
My idea is based on this solution for a separate problem: There could potentially (not regularly) be 10-50 users in an area with only a few BLE "nodes" and I read at bluetooth.org that I could setup a dynamic connection system, basically rotating connections through all the users.
My idea is to setup a similar dynamic system where the central device (not the iPhone) disconnects the device on regular intervals (30-40 minutes) and then the iPhone will reconnect.
Is this something that some feasible? Is this against the iOS development guidelines? I was unable to find anything explicit about this. I have also asked on the iOS developer forum, but unfortunately it is not as popular as this site.
Thanks in advance!
Xcode -> Project target -> Capabilities -> Enable background mode
Check Uses Bluetooth LE Accessories
Capabilities
Also enable the following key in .plist file
Required background modes
App communicates using CoreBluetooth
Plist
I want to be able to pair Microsoft PixelSense hardware with multiple mobile devices via bluetooth and I want PixelSense to know which device is which. So if I place two phones on a table, PixelSense should be able to label them by device name. My initial thought was to have the phone display an Identity Tag that has encoded its Bluetooth MAC address so that it could associate them but PixelSense sees in infrared and can't read the phone screen so that idea is out. Can anyone think of another way to do this?
Microsoft has demonstrated a way to do this in their Mobile Connect sample application. They've ingeniously used the fact that almost all phones have a camera that faces down when the phone is placed on a flat surface. So they created an app that will read incoming color data from Surface while the phone is sitting on it.
So it goes like this:
The Surface app starts and makes the Surface computer itself visible on bluetooth (although you may have to do this manually in admin mode, can't remember)
you run the mobile app on your phone, click connect, and place it on the Surface at a designated spot
the Surface flashes a serious of colors into the phone's camera
the phone decodes those colors into a pin and scans through all the open bluetooth devices it can see until it finds one that is a desktop running the appropriate service and accepts the decoded pin.
Now the two are connected with no need for manual input and the Surface knows which physical device it's talking to because it knows which pin it displayed to each device.
*Note - They don't actually allow multiple simultaneous connections in this sample app, but I see no reason why it wouldn't work.
One issue with this approach (other than being pretty complicated to code), is the need for the app on the phone. One way to make it easier for people to get the app is to display a Microsoft Tag or qrcode on the Surface for people to scan (they're much more likely to have a scanning app already). I don't think there's any getting around the need to have something installed on the phone if you're using bluetooth anyway.