I have a custom embedded device with a Bluetooth low energy stack. The device is advertising itself until a connection is requested, I pair and connect to it via the Bluetooth menu in Windows 10, I can read/write to my custom GATT services using the following BLE GATT functions from the Win32 API.
For my application I need to receive high frequency data using notifications on a characteristic so I enable it using the same API as stated above and receive the correct data but too slow. The default connection parameters Windows is using is not enough and I want to update them so I can receive notification events at higher frequency, but Windows API does not provide such function. I had the same problem when connection to an Android phone, and I solved it by requesting connection parameters update from the device (the slave in the connection) and the Android phone accepted it and everything worked as expected.
The only problem is when I'm trying to ask for a connection parameter update from the device when connected to a Windows master, I don't receive any response (no accept nor reject), meanwhile I still receive notification events so I know the connection is still active. And the weird thing is that if I hold the device closer to the computer's Bluetooth antenna it does receive a response and update the connection parameters like intended.
Any idea what's going on? Is it a bug in Windows stack?
The fact that holding device closer to antenna helps should be verified. Try it multiple times in a different way.
You mentioned Android, does holding device further from Android also prevent connection parameters update?
If this proves true, I'd say the device is faulty. I would compare the behavior between different devices, better if they are from different manufacturers or at least models.
Related
We are controlling the sonos via a small IOT device. This device will be placed at the homes of our customers.
In our home automation system we need to know the playbackstate + volume of the players/groups.
At which polling rate can we ask these parameters ?
We cannot use a cloud server to handle the subscription events.
I tried to put a https webservice in the IOT device with a self signed certificate but this doesn't work.
After I have posted the subscription I get a request in my webservice but the cloud sonos server disconnects immediately.
Probably because of the certificate is self signed - Or can there be another reason ?
Is there another way to recieve status events ?
During discovery In the players Json object there is a key 'websocketUrl'.
The documentation says "The secure WebSocket URL for the device. See Connect for details".
But I cannot find more info about this.
Can this be used ?
At which polling rate can we ask these parameters?
Consider using subscriptions instead of polling. See this answer for more: https://stackoverflow.com/a/60893119/4902948
We cannot use a cloud server to handle the subscription events...
Or can there be another reason?
Is there another way to [receive] status events?
You must host a service that satisfies a set of requirements to receive events. See this answer for more: https://stackoverflow.com/a/57189717/4902948
Also see Details on API credentials and events in New features in versions 11.1, 11.2 (S1), & 12.0 (S2).
Can [the 'websocketUrl'] be used?
This is not publicly available for use.
It would be a lot easier to use the (undocumented but more useful) UPnP APIs. You could simply Subscribe to the UPnP RenderingControl endpoint, then you will get an event every time the volume changes. To find when the track changes, subscribe to AVTransport endpoint.
You can do this with a local server (this is how every Sonos app works after all) and no special cert requirements either.
UPnP events are described in the UPnP spec.
Your question doesn't provide details about the language you're using, but if the device is powerfull enough to run node, you have a good change with my sonos library.
You can just pull the required information from the device as often as you like. Or use the build-in event subscriptions. If you use the events, it will automatically setup an http listener and automatically subscribe to all the events you're listening for.
Events are instant (as in 50ms-100ms after the event took place on the device).
If you request information it is send directly to the device and the device will respond with the answer. Pulling multiple data points per second has never been a problem to me.
Warning as stated above, this uses the undocumented local UPNP api, but since their own app also uses it, I'm guessing that won't change soon.
According to Test Case 1.30 of the Google Cast Test Cases:
Step: Turn sender WiFi off for 20 sec
Expected Result:
Sender does NOT crash
Cast icon not filled
Receiver continues playback uninterrupted
Step: Turn WiFi on and connect to same network
Expected Result:
Cast reconnects, cast icon filled
The above is listed as a P0 test case, where "Your application must not launch with a P0 bug." However, apps using the Remote Display API can't play back media when the sender is disconnected, because the content is being cast locally over WiFi. Additionally, I've noticed that on Android, the official Google Cast app's Cast Screen/Audio feature doesn't attempt to reconnect after a WiFi disconnect.
Are apps built with the Remote Display API required to fulfill the reconnection and continuous playback requirements?
As far as I know Remote Display API only has a feature of keeping a remote display session active and to resume after app backgrounding. Documentation doesn't mention about reconnecting after a WiFi disconnect.
And reading further through additional documentations, Media Playback Messages states that:
Google Cast sender applications control the playback on the receiver device by sending messages in JSON format to the receiver application. Likewise, the receiver sends messages back to the sender, also in JSON. The messages may be commands from the sender that change the player state, responses to those commands from the receiver, or data structures that describe the media for the receiver application.
From what I understand, you might need to initiate the creation of connection again after a change in player state or after a WiFi disconnection.
I would know if there is a way to determine if the application connected using 3G or WIFI network.
You're not going to be able to determine this on the server side only. The only thing you can check is the HTTP user agent, which will help you figure out the device. However a connection is just a connection, there's no way to determine how it is connected without the device telling you. If you are developing a local mobile application then you can either do different logic on the device or send additional information about the device's connection.
There is device connected to PC via 1Gbit Ethernet. WinXP/7
I want to capture data in the following way:
PC sends command to devices (initiate data acquisition)
Device is sending data to PC
User application waits for acquisition
Driver saves data in the memory
Device sends command to notify that it finished acquisition
Driver generates interrupt and user application starts reading data from driver
I have no idea how to implement that.
There is NIC driver. There is NDIS. Can user application communicate with NDIS?
Do i need to write additional driver to communicate with NDIS?
Your problem really has two parts:
How to send commands to the device
How to capture data sent from the device
The first problem has two possible solutions, depending on whether your device accepts commands encapsulated in IPv4/IPv6, or whether it requires some other low-level protocol. If the device accepts commands encapsulated in IPv4/IPv6, then just use the sockets API in your favorite programming language.
If the device requires its own non-IP protocol, then you need to add an NDIS protocol driver. There is a sample protocol driver that is included with the Windows Driver Kit; this driver essentially opens a channel that allows a usermode application to send any kind of packet. (This would be a security issue if it were deployed widely, which is why it's not a built-in feature of the operating system.) You may need to modify the protocol driver to selectively listen only for control messages from your device.
The second problem — packet capture — is already solved. You should be able to pull existing software off the shelf and integrate it in your solution. Microsoft Network Monitor has an API that you can use to easily start/stop packet capture, and iterate through the captured results. Alternatively, some people use WinPcap.
I've absolutely no idea if this is possible and how it would work.
is it possible to give users a phonenumber where they should send an sms to.
e.g. the sms contains
name
some code
i want to track how many sms are sent to this number.
i want to read the sms text and use both nodes
they weird way i imagine this: i buy a prepaid simcard from any phone provider, i plug the simcard into any device (sim-reader :) ) connected to my computer. my computer is ONLINE. so my computer is kind of transformed to a mobile phone. some software is able to retrieve those sms and i can use the data in it.
is that even possible, if yes HOW?
You can use e.g. gammu to send and receive SMS from a cellphone connected to your computer - essentially creating a SMS gateway. I've succesfully used it in the past in this setup (newer phones have serial port emulation through USB, for older ones you need a model-specific serial-to-phone cable):
my program <-> database/textfiles <-> gammu <-> serial port <-> cellphone
The operation was as follows:
gammu ran in the command line/daemon mode, with a watchdog script restarting it (and the cellphone) if the cellphone became unresponsive (this was a really old phone; a watchdog is probably not necessary with anything > 2006)
gammu polled the cellphone for new messages, those were store into a "received" table in the database.
gammu also polled an "outgoing" table in the database for messages I wanted to send, and sent them through the cellphone.
my program was a web frontend for reading the incoming messages or inserting the outgoing ones.
(Gammu has an API to interface with the cellphone directly, without the database; I decided to keep the backend and frontend parts separate, and since the frontend was using the database for other things anyway, it was easiest to go that way; also, I was using an old phone for this, and needed the frontend to run even if the cellphone wasn't responding)
There are several possibilities listed here. But it depends on the phone you are using. Symbian, iOS, Android, Windows Mobile. But basically it is possible using a GSM Modem.