SfChart won't render data points coming from a bluetooth device.

Hello Great People of the Community Forum.

In our mobile app we've been using a number of various SF Xamarin.Forms components with great success. However, we've bumped into a critical problem using the SfChart in the following scenario: a bluetooth device (connected to a mobile android/ios device) is constantly (about every second) sending data points that have to be rendered in the chart.

Unfortunately, the chart refuses to render all the points. After the app has been launched and the data points start to flow into the chart, at best, the first 2 points will be rendered and then the chart stops updating the series (we use FastLineSeries). More often though, no points are rendered at all.

If we generate (random) data points after a test button is clicked on the app screen the chart renders them just fine. It also works when a random data point is generated at every timer tick.

The following combinations of getting the data points (from the bluetooth device) into the chart have been tried:

- Data points are sent immediately (after they have been received) into the chart.

- Every time a new point is received the entire series gets rebuilt (to include the new point) and re-attached to the chart.

- Upon receipt, the data points are first pushed into a stack and then are popped at a timer tick that runs every 3-5 seconds (tried different times).

Nothing worked.

As alternative, we've used OxyPlot and it worked just fine and w/o any tricks (the points are immediately rendered upon receipt). One key difference we observed between the SfChart and the OxyPlot is that the latter does not bind to the data - you have to refresh/re-render the chart every time a new point is added.

We could try a similar approach but the SfChart does not seem to have an option of rendering the data w/o binding.

We like the SfChart over OxyPlot but this problem is a showstopper and we cannot rely on SfChart in this case. If someone has a similar case and has found a workaround that could share with us it would be greatly appreciated.

Thanks,

Hi Alexei, 

 

Greetings from Syncfusion, 

We have prepared a chart sample integrated with monitoring Bluetooth signal by using opensource plugins to reproduce the reported issue. The sample will be downloaded from below location.  

 

Sample: http://www.syncfusion.com/downloads/support/directtrac/general/ze/SampleBluetooth1621237620.zip  

 

Reference link:  

Source link: https://github.com/aritchie/bluetoothle  

NuGet link: https://www.myget.org/F/acrfeed/api/v3/index.json  

 

We directly integrated the chart with sample provided by the Shiny plugins (source link mentioned above) 

In that sample, we plotted the chart data points based on the available device and its signal strength until the scan complete. And it’s worked fine.  

 

As we are not aware of your application, what kind of Bluetooth device you connected with and not know what kind of model and view model you maintain, so we requested you to share the chart configuration and view model codes, or if it is possible, please revert us modifying the above sample based on your application scenario. It will be more helpful to analyze your problem and provide you exact solution for your requirement.   

  

Regards, 

Bharathi. 

Thank you for the prompt response. Unfortunately, we cannot integrate your example into our app as we use a different type of BLE plugin (https://github.com/xabre/xamarin-bluetooth-le) and your sample code would require us to do quite a lot of rework. If we were highly confident that the plugin was the root cause we would definitely make that change.

To answer your other questions, our app uses a BLE heart rate monitor that is capable of reading rr-intervals (not just average heart rate).

For the series that we cannot make render in real time (it renders fine when the series is simply loaded once, before displaying the chart) is defined as ObservableCollection< ChartDataPoint >. 

The chart configuration is provided below. The series gets added programmatically right before a connection to the HR monitor is made using the chart Series.Add method.

Back to my original message, is there an option to add the data to render in a non-bindable manner? Just curious to (in)validate that theory (that data binding might be the reason).

Also, if it helps, another observation we've made is that it seems that the app takes a lot of CPU power when getting and rendering the data (we do have a number of algorithms running that process the data points from the monitor and before they are sent to the chart. Maybe, that load somehow slows down the UI thread but again other ui components render ok on the screen with the chart. 

Please let me know if you have any questions.

Hi Konovalov, 

 

We have validated your query, we suspect the chart is loaded with bulk amount of data, so it slows down the UI thread. So, we suggested to use BeginInvokeOnMainThread() to load the data in background thread, it will helps to increase the performance.  

 

In other hand, we can able to hold the chart from updating of each data added to the collection, Using SusbendSeriesNotification and ResumeSeriesNotification methods in chart control, the chart will not respond to any change in the items source collection after the SuspendSeriesNotification method is invoked. It will be updated with latest data after the ResumeSeriesNotification method is invoked. 

 

[C#]:  

 

 

Some other guide lines to increase the performance: https://blog.syncfusion.com/post/7-tips-to-optimize-xamarin-charts-performance.aspx#comment-10677  

 

We have prepared simple sample with dummy data, that will be downloaded from below location.  

 

Sample: http://www.syncfusion.com/downloads/support/directtrac/general/ze/SimpleSample-906735187.zip  

 

Please refer the below help document for Chart performance. 

https://help.syncfusion.com/xamarin/sfchart/performance  

 

If you still face the problem, please provide the chart configuration code snippet it will help us to investigate further.  

 

Regards, 

Bharathi.