I am writing a real-time game client. It works great on desktop, but as I come to implement it on iOS, the packets seems to cluster together and only send ever half second to 1 second which yields a very jumpy experience.
I am using the low level sys/socket library so a send simply looks like
send(this->sock, bytes, byteslength, 0)
As I said, this does not have this behavior on a desktop system, but I assume there is some sort of power saving logic going on here that wants to cluster the data into a single packet instead of sending the packet as soon as send is called. Certainly there must be a way to force the fast send.
With iOS CoreBluetooth, when sending a relatively large amount data, it's important to break it up into 20 byte chunks and then write them one at a time into the peripheral object. This is pretty easy to do when using a WriteWithResponse characteristic: write 20 bytes, wait for the callback, write the next 20 bytes, and so on.
But what about with a WriteWithoutResponse characteristic? I need to send of 1-2kB of data as quickly as I can over BLE. WriteWithResponse is very inefficient at doing this, because it acks every 20 byte packet. Error correction and reliability are taken care of at my application layer, so I have no need for BLE to ack the data.
The issue is that WriteWithoutResponse does not give you a callback, because there is no way for CoreBluetooth to know when the data was actually written. So the question is: how do we properly space out sending a large amount of data using WriteWithoutResponse?
The only solution I've thought of is to do the following:
Get the connection interval and the number of packets that the link is capable of per connection interval.
Immediately write X packets of 20 bytes each, wait Y time, and repeat until there is no data left. (X = Number of packets per connection interval, Y = The connection interval)
There are two glaring problems with this approach:
CoreBluetooth does not expose the Connection Interval to us (why??). So there are two options. The first being: guess. Probably either a worse-case or average-case depending on your preferred connection parameters, I think iOS likes to pick 30ms. But this is a bad idea because a central has the right to completely ignore the suggested parameters. The second is that you could have the peripheral store and transmit the agreed upon CI to the iOS device. The issue with this is that you can't send the CI until iOS device has finished discovering the services and characteristics and subscribed to the appropriate notification. So you'd have to either put in a somewhat arbitrary fixed delay after connection before sending the CI, or send a small amount of data from the iOS device notifying the peripheral that it is ready. Both create latencies and are pretty poor solutions.
We don't know how many packets per connection interval can be supported. There is a theoretical maximum of 6. But the average case is probably 4 or less. It is also dependent on the peripheral.
Of course a great option for sending large amounts of data is to increase the MTU size to larger than 20 bytes to accommodate our large amount of data. But it seems few peripherals support this; ours does not.
Anyone have any insights on how to solve this?
If You are supporting iOS 11:
iOS Website
#property(readonly) BOOL canSendWriteWithoutResponse;
This property lets you know, if Buffer is filled up or not and can transmit more without response.
After each transmission keep an eye on this variable and a call back: Peripheral Delegate
peripheralIsReadyToSendWriteWithoutResponse:
Which should be sufficient to let you know, when to send more data.
I am looking at how different mobile devices from different vendors implement the power save mechanisms defined in the 802.11 standard. My only way of viewing what these devices are doing, what their frame pattern is, is through wireshark captures.
From what I understand,a common behavior to all mobile clients is for them to send:
a Listen Interval value expressed as an integer in the (Re)Association Request
a Null Function frame or a QoS Null Function frame with the power management bit set to 1 to announce the AP that they are going into PS mode, turning off their Tx ans Rx and that the AP needs to start buffering traffic directed at this now-dozing STA.
Beyond this point there are several different mechanisms through which these devices get their traffic back once they're awake. By far the most common behavior I have seen in the captures is for them to send either a Null Function or a QoS Null Function frame with the power management bit set to 0 and the AP proceeds to send them the traffic, because the mobile device is now effectively operating in Awake Mode.
The 802.11 standard, however, specifies that a mobile device should either send a PS Poll frame to specifically ask for its traffic or implement either S-APSD or U-APSD mechanisms. However, I have seen none of these happen.
Does anyone have any experience with these mechanisms and can tell me how I can check which mechanism each device implements?
trigger frame is the latest style for power save mechanism ,sourcing from apsd mechanism.
ihpone4/4S/5, sta will inform the ap the power save state through power management bit .
when ap check sta is awake though null data or other data frame(psm bit),ap will send the buffered fame at once.
ps-poll is inefficient for current product, one poll one packet.
UAPSD:
STA will announce its capability for uapsd (ac) through wmm ie . it will tell ap which AC is supported for STA. u can check the (re)association packet to get the information .
I know that in a CAN controller if the error count reaches some threshold (say 255), bus off will occur which means that a particular CAN node will get switched off from the CAN network. So there won't be any communication at all. But what if the above said scenario happens while the car is moving which contains the ECU (includes the CAN controller)?
Is there any auto-recovery mechanism in a CAN controller to avoid any of the above situations?
During bus off, the node will be isolated.
CAN waits for the mandatory time period, 128 x 11 bits (1408 bits - 5.6 ms for a 250 kbit/s system) of time, and then tries to re-initialize the node.
Yes, if a CAN Tx error count reaches 255, a node will turn off and potentially reset itself. A good implementation will not continue resetting a node if the problem persists.
In addition to this safety mechanism, ECU's (electric control units) also time the duration between valid transmissions of the messages they expect to receive. Therefore, if the engine controller goes offline, nearly every ECU in the vehicle will report "Lost Communication with the Engine Controller."
Typically, these type of CAN problems are identified by DTC's (diagnostic trouble codes) beginning with U, like this one: http://www.obd-codes.com/u0115
Depending on the severity of the issue, the vehicle might enter a "limp home" mode, or might be totally disabled. Problems with the CAN bus on a vehicle are extremely rare, unless there has been some tampering.
The recovery mechanism depends on the software stack that's being used. Most new vehicles have AUTOSAR compliant software implementations. In the AUTOSAR communication stack, the CanSM (state manager) module has configurable BusOff Monitoring and Recovery. You can read more at http://autosar.org .
A BusOff however, is a serious situation in a running vehicle. How this is handled at the vehicle level is very specific to the system design. But, in most cases the system would go into a safe mode of operation and all parameters would take pre-set fault values to let the vehicle run with a reduced functionality. You would see the warning lamps on the dash go off to alert the driver. ECUs typically comply with some level of ASIL (https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level) standard. This makes sure that such situations are thought of and taken care of during design and development.
Nothing spectacular will happen, even if the Engine Control Unit looses CAN communication. The car will continue running.
When bus-off occurs, the CAN network isolates that node and then resets that node which can able to start communication.
As you mentioned, after reaching a specific error count, that node gets disconnected/prohibited from transmitting anything on the bus. This is a description for the bus side.
On the controller side, every CAN controller generates an interrupt on BUS_OFF. It is the controller's responsibility that it should reset the CAN controller and bring it back to the normal state.
This is strictly followed for every CAN controller in any car. And this all happens in a few milliseconds... So for the driver, nothing happens!
When the ECU detects a BUS_OFF fault, the ECU should stop its emissions so this is a good question to ask.
There is an auto-recovery mechanism:
For the first three detections, the CAN controller resets its registers without a delay
For the next detections, the ECU waits 1 second before the reset
There is something called limp-home mode for the cars. That is the condition when all the ECUs fail in the car network. Then a set of default parameters for the ECUs are initialized and then the system, i.e., your car can continue running only for some time before it is properly serviced by the OEM.
I know this is an old thread, but the answers are a bit different from the situation I have observed, in relation to the OP question.
From experience, I'm have an issue where my ECU stops communicating with the diagnostic tools while the engine is running, apparantly it has entered the CAN off state. The only reason I know is I have a OBD 2 plug in monitor for engine parameters. I don't get ANY DTC, well most of the time anyways.. sometimes I get DTCs that are not applicable to my vehcile, and some U codes.
That said, the vehicle continues to run just fine, and if I didn't have the plug-in monitor, I would have no idea there was a problem! I'm now pretty sure the ECU for the Engine is having communication problems, and hitting the error counter and shutting off, it's the only thing that makes sense. I checked the CAN signals with a 2 channel O-scope, and they are a bit noisy compared to one of my other cars, so my next step is to swap the ECU and see if that fixes it. I already swapped out the TIPM (Total Integrated Power Module), it serves as a router of sorts between the 2 CAN networks, to the OBD2 port. That apparantly wasn't it.
if a CAN Tx or RX error counter reaches 255 , the node will turn off and be isolated
What happens if a bus-off error occurs in a CAN controller while a car is in motion?
1)HARD SWAPPING can be done in can network.
eg: Assume four(4) nodes(ECUS) are connected in can bus network.if we disconnected one
ecus then also can bus works properly.
2)In BUSS OFF condition it can hear every signal on the bus network but it cant transmit
mssgs(signal). If the car in motion or in rest position.
eg: Ecus(ABS) are using for better performance but actual work is done by actuator(DISK BRAKE).
I'm writing a fairly low-level driver for a wireless card, and while most of the spec is fairly straightforward, I haven't wrapped my head around a single question yet:
If my station is in power-save mode and its receiver is turned off for an extended period (say, 10 seconds) between DTIM frames, and the access point is rebooted in the meantime so my association is lost, how can I detect this?
I'm aware that the most common case will be that synchronisation is lost thoroughly enough that I will miss a number of beacons and simply go back to the AP search afterwards, but if by some lucky chance I get to see beacons, is there some way to find out that this is a new "instance" of the same AP?
I can think of
a short(er) TIM field -- however I believe APs are allowed to shorten the TIM information if no traffic is waiting
the AP timestamp changing unexpectedly.
the "number of beacons to next DTIM" field changing unexpectedly.
Being a perfectionist, I'd like to know if there is an entirely reliable way to detect that the AP has been rebooted, rather than just putting together clues.
I would suggest that you look at the TSF in received beacon frames and
if it differs too much from the TSF you expected you send a NULL-data
frame to the AP. If the AP was rebooted it should respond with a
deauthenticate frame with reason "Class 2 frame received from
nonauthenticated STA".
I don't have any knowledge of wireless cards at that level, but I'd take a practical route and analyze the communication from the AP just leading up to the disconnect for a pattern that matches a typical shutdown sequence; for example, "no more traffic, a sudden loss of DTIM sync, and then an AP announcement".
Off the top of my head: maybe look into Kismet's AP detection and analysis code for an idea or two. I'd bet someone else has encountered this problem before.
Cheers!