We have developed an application with Movesense. The application connects and subscribes to the Accelerometers.
It is running for 35 seconds and receives data from the sensor.
Each time after 35 seconds the sensor stops sending data (Not sending onNotification(String data)) and after a few more seconds disconnects. Few more seconds later it reconnects and continues to send data.
This totally ruins the user experience and the ability to work with Movesense.
We have tried 4 different Movesense sensors. The problem exists in all.
Also we updated firmware to all our sensors, but the problem did not go away.
In the Device Documentation in the file "Changes.md" we found the following 2 lines:
"Known Bugs:"
"HR stops sending data after Acc/Magn/Gyro subscription"
Reading trough most of the device-lib documentation, and the issues in Stuck-overflow (i.e. here) we were not able to find any further documentation about this issue.
We have a few obvious questions:
1. Is what we see is the "Known Bug"?
2. If yes, is there any further documentation on it?
3. If yes, is there a known workaround for it?
4. If no, what would you recommend to do?
Thanks,
Eric.
Update: After testing with mobile devices with API 23 or higher the problem disappeared. The original mobile device was API 22. Also, since we don't have another device with API 22 or lower, we cannot rule-out that the API 22 device has some issue in its Bluetooth which may not be related to the API.
I am leaving this question unanswered since we would still like to ask how or where to find more details about the known bug “HR stops sending data after Acc/Magn/Gyro subscription” described by this sentence in the Movesense Device Lib documentation.
Thanks,
Eric.
Related
I have an Asus P00A tablet (Android 7.0, API24) on which the BLE stops after some hours. (This affects any BLE app, not just my app using Android Beacon Library). Apps start working again if I manually switch off BLE then switch it back on.
The BluetoothMedic auto-fix system did not work for my tablet. It runs every 15 minutes but does not find a fault and so does not "power cycle" the Bluetooth. However, I hacked the BluetoothMedic class, adding this:
public void cycleBluetooth(Context context) {...}
and attached this to a button. I find this will restore BLE functionality. So I wondered what would happen if I unconditionally reset the BLE every 15 minutes. I added:
public static final int ALWAYS_RESET = 4;
and then call medic.enablePeriodicTests(context, BluetoothMedic.ALWAYS_RESET);
and add code inside BluetoothTestJob.onStartJob() which then calls BluetoothMedic.cycleBluetooth(). This behaves as expected and so far my app has run perfectly for 18 hours.
I am interested in any advice, such as:
1 Are there any tests other than the two in BluetoothMedic that I can run to detect that my tablet's Bluetooth has stopped? (I am happy to experiment).
2 Any comments on the hack I describe above? Should it be OK to unconditionally reset the Bluetooth every 15 minutes?
3 If the Bluetooth is reset ("power cycled") then is the rest of the Android Bluetooth Library OK with this? That is, will it carry on with monitoring and ranging that has been previously set up, or does the application code need to set take any action to get things going again? Note that this would apply to resets by the existing enablePowerCycleOnFailures() code as well as my ALWAYS_RESET hack above. (Maybe there are some crashes that could happen if the power cycling came at the wrong time?).
4 Could I suggest adding a callback so the application can learn if the Bluetooth has been cycled? Perhaps as a parameter to enablePowerCycleOnFailures()
5 I understand that background activities can be stopped by the OS, especially with Android 8. Would this also affect the regular 15 minute tests set up by enablePeriodicTests()?
The Android Beacon LIbrary's BluetoothMedic, as currently built, relies on the operating system's error code returned by a scan failure (or an advertising failure) to decide if the bluetooth stack is in a bad state warranting a power cycle.
For scans, if the onScanFailed callback is called with an error code of SCAN_FAILED_APPLICATION_REGISTRATION_FAILED which has the value of 2, the module considers it worthy of a power cycle..
For advertisements, if the onStartFailed callback is called with an error code of ADVERTISE_FAILED_INTERNAL_ERROR which has a value of 4, the module considers it worth of a power cycle..
These values were determined via experimentation, witnessing that on some devices, once an error callback is called with these values, bluetooth on the device would not work again without turning it off and back on. You can see the discussion of this in this thread.
You may want to see if there are other error codes on the Asus P00A that indicate a problem worthy of cycling bluetooth. To do this, wait for a failure, and see if attempts to start scanning call the onScanFailed callback with a distinct error code. If such error codes exist, this would be a better solution than cycling power to bluetooth regularly, as cycling power to bluetooth does break BLE GATT connections and the operation of bluetooth classic functions like speakers. The Android Beacon Library itself recovers from these power cycles just fine, although it will obviously not detect beacons until bluetooth is back on.
Because the BluetoothMedic uses the Android Job Scheduler for periodic tests, it is not affected by background limitations on Android 8+.
If you are interested in augmenting these functions in the library, please feel free to open an issue in the Github repo, and issue a Pull Request if you have code to share.
I have implemented successfully the pires/obd-java-api OBD Interface in an Android app and everything works as expected, expect that after about 1.000 - 1.500 API calls, the API stops responding.
Did anyone come across the same problem?
Is it maybe necessary to send a reset command to the OBD dongle after some time?
I thought it might be that the API is collecting data and a memory problem occurs, but onTrimMemory is never called.
I assume API means Standard Pids(mode 1)then OBD will not response in following case
1: TimeoutCommand is too low, set 255
2: may be not proper power supply
Note: ResetCommand is used as initial command once before fetching real time data.
you can refer android-obd-reader sample app:
https://github.com/md-sohrab-alam/android-obd-reader
People! I thought to include it in original question but didn't.
WHILE VOTING, YOU ARE ALLOWED TO COMMENT WHY DID YOU VOTE?
Please use it to enable learners get theirs things done and convey their thoughts/issues to others better way. Not everyone knows what you think. Thanks
In Short:
I need to synchronize clocks of two Android Phones (placed close to each other OR not; both cases) with each other AND with up to an accuracy of a few milliseconds (10, 20 ms max).
Either sync the clocks
Or get an offset of one from the other
What I am Doing:
I have a developed app that I am using to measure different GSM network statistics. I am using telephony manager to get three states (OFF-HOOK, IDLE, RINGING). Phone A calls phone B. Both phones are running an app that is saving the time-stamps with regards to the states mentioned above. After making many calls I export the time-stamps in a data file and analyze them to get different network stats.
What is my Issue:
I have to cross-match the time-stamps to get stats. Now the problem is that if the phones' clocks are not synced then I will not be able to get exact stats (e.g. how much time it takes to get phone B in ringing state after phone A initiates a call?).
What I have Tried: So far I have tried to sync clocks with NTP, GPS or atomic clock. I have used ClockSync (Android app) to get offset of both phone clocks from atomic clock. The issue is that this offset depends on RTT of network packets from my phone to server. I gives my difference of up to 100 ms when I check offset two times (tap refresh two times consecutively). The offsets at both phones can lead to error of up to 200 ms which is unacceptable for me.
All other syncing apps/methods have same issue.
Possible way forward: (What I think). I may develop an app that
takes the time-stamp at phone A
transfers that to phone B via Bluetooth or WiFi (connected to same router),
B then compares that time-stamp with its own clock, calculates offset,
And I run my original app, run experiments and,
Use the offset to correct time-stamps before processing data
Your Comments/Suggestions: How to do it? And comments on the method described in last part..
I've got a problem. I'm developing an android application that scans for wireless accesspoints/routers. I've been testing a couple of devices and I'm getting scan rates of 2, 1, 0.5, 0.1 etc. scans per second.
My goal is to reach 10 scans per second because a router can send beacons 10 times a second. And we need this for our application.
Is there away to make this possible? Perhapse hack a rom and replace the wifi drivers? I've been looking in to this but I can't find anything about this frequentie inside the driver.
The driver used is BCM4329 driver, I can't find any datasheets of the BCM4329 so it's kinda hard to figure this out.
Thanks in advance.
flitjes
I'm not familiar with driver development but I know it's one of the hardest thing in computer science so unless you have good knowledge in linux kernel development I would forget about it.
Moreover, you still need to scan the 12 Wi-fi channels to be sure that you are detecting all access points. An access point broadcasts a beacon every 100ms * 12 channels = 1.2 seconds. Spending less time than that and you risk missing access points.
You don't need to change anything in the device driver, Android makes it available to you to scan for access points. See the documentation.
Although requesting that many scans will probably not be very good for the battery life and the responsiveness of your app...
Your assumption that beacon rate is 10 per second is incorrect. This is really an AP configuration parameter, although 10 per sec is default in most. Besides that, APs do not send beacons simultaneously, if this happens, it's called a collision and a back-off algorithm is used for retransmission. In addition, even scanning 10 times per second doesn't make it certain for you to capture all beacons, like was pointed out in the previous answers.
if u use 4339 driver, you could not set the scan rate in driver or android api which is fixed in 4339 firmware, scan is about all channels && time u spend on each channel, according to the 80211 spec, which is part of mac && phy. in this case u just need to get the beacon, so u should use passive scan and use fixed channel && MaxChannelTime u want.
u have to ask broadcom for speical fw to figure out your problem,
IEEE
Std 802.11-2012 page 978
10.1.4.2 Passive scanning
If the ScanType parameter indicates a passive scan, the STA shall listen to each channel scanned for no
longer than a maximum duration defined by the MaxChannelTime parameter.
Android provides the following method to determine the network operator:
http://developer.android.com/reference/android/telephony/TelephonyManager.html#getNetworkOperatorName()
However even the documentation specifically says:
Returns the alphabetic name of current registered operator.
Availability: Only when user is registered to a network. Result may be unreliable on CDMA networks (use getPhoneType() to determine if on a CDMA network).
The problem is that we need a reliable way to detect the carrier so we can identify the traffic source. Has anyone had a similar problem and if so, what is the best solution?
My phone is on Verizon Wireless. On a daily basis, I drive through areas where my phone is roaming and/or has poor reception. Using scripting layer for android, I will log the results of calling getOperatorName() once every ten minutes over the next week.
There is another method that might work in the android.telephony.cdma api. The documentation there is missing the reliability disclaimer. You would only get a Network ID instead of a name. Unfortunately, this requires API level 5 instead of 1 if that matters to you.
Logging the results of the getOperatorName() method yielded nothing special. When I had no service it consistently returned null and when I had service it consistently returned "Verizon Wireless." I'm sure that's not very helpful.
Edit: Addition and correction.
Added - Explanation of link
Corrected - API level 5 not 17
Edit 2: Test results
I am currently looking for a solution for this problem as well. According to this thread one could use CdmaCellLocation.getNetworkId and CdmaCellLocation.getSystemId. Since there are no CDMA networks in Germany, I am unable to check if this works...
You think maybe this was one precurser to Google pulling cdma support? Play within the frameworks or find you another playground is what I hear Google saying. Well that and the fact that carrier apps burned into roms have at times left gaping holes in security.
As to a possible answer to your question... from where are you able to pull info? APN settings might tell you or an assert to a known carrier line in build.prop could pull the info I might need for example. (I do the hobby roms). Then again if you physically inspect a phone, the carrier is usually branded ;) From what vantage are you pulling the info?
Rob