Can I specify more than 8 values per frame in the CAN puncture description file? For example, I need to get several different bits, I also need to get several single bytes, and double bytes from one frame.
And it’s convenient for me to indicate this in one frame in the xml file.
Will such a view be correct?
Topic moved to ‘RealDash CAN’
Sure, you can specify a unique value for every 64 bit if you wish.
For example, see Adaptronic frames 0x31b and 0x36c in this file:
https://github.com/janimm/RealDash-extras/blob/master/Channel_description_files/RealDash%20CAN/Adaptronic/adaptronic_can_simple.xml
Optional way is to use ‘startBit’ and ‘bitCount’ values in XML to match the desired bit.
Can you share the Xml description of the example on github, so that it would be clear which parameters apply to sending, and which to receive, or which can be applied to sending and receiving simultaneously?
So for example writeinterval can only be applied to sending. Right?
You can set the ‘writeInterval’ to any frame, its then written back to CAN on that interval.
How can I limit the flow of values received from CAN?
For example:
I don’t want to get the engine temperature very often, but I want to get revs and Speed more often …
In general, does such a strategy make sense?
I mean, the performance of the speed data stream will not be lost when a huge number of secondary signals are received, which should not be updated so often?
Or is RealDash doing just fine with any thread?
I still notice a little jerking in the movement of the tachometer needle on the same android device with the s912 processor …
But so far I can’t understand what is the reason. In rendering or in stream processing?
The fact is that in the monitor, bytes are very fast. Lightning fast.
And in graphical form on the whole screen, it is the arrow sensor with the value “smooting 100” that behaves a little strange, visible small frame drops.
Even on a lightweight standard panel.
My arrow weighs only 5kb.
What else can affect arrow performance?
What can I see?
I am trying to get rid of this effect:
https://youtu.be/F9hynIQ-WNA
In slow motion video:
https://youtu.be/0zPLLr5lRaM
Typically CAN devices send frames with different priorities with different frequencies. RealDash does not really care about this, it reads all frames as they come in and sets the values if frames are known from XML. The sender is responsible for controlling how often each frame is sent.
As for your video examples, I don’t see anything wrong with them. Maybe its my old eyes.
Thank! For answer. Maybe I myself am very critical of my research … As they say: “There is no limit to perfection”
In any case, thanks for your opinion))
Everything in the world is relative and relative to my point of view, your view is not at all old, but even new …
One thing that you may want to consider with your CAN device is that keep a cached copy of the frames that was last sent to RealDash, and only send the frame again if any of the data bytes have changed as there is no point to bombard RealDash with CAN frames which data does not change.
In addition to this you may need something like ‘send at least one frame per second’ to prevent RealDash timeout while waiting for frames from CAN device.