I still continue to record short bursts of absolutely all data sent to RealDash via arduino.
I practically got rid of this phenomenon, excluding random errors of reception by the “if” operator, but the data is very very rare, but still confused.
I’m pretty sure the problem is in the arduino itself or the MCP2515 module that I use …
and I saw these problems with other users.
I do not ask developers to fix the hardware problem, this is impossible.
I suggest users who encounter the same spike, twitch, data.
Guys. Let’s unite, and together we will find a workaround …
who will support?
By the way, 174 and older RealDash in the monitor of the comport I ID, which settle at the end of the list. they look like incomplete, distorted data, they are also rare.
I understand that this is a filtering system?
Jani. In and written in 174:
"
In this version, error handling is improved when parsing CAN frames according to the connection types “RealDash CAN” or “CAN / LIN adapter”. Because CAN systems controlled by interrupts can write a CAN frame to the serial port, while the previous recording is still in progress, causing the frame bytes to alternate into the serial stream. RealDash is trying to detect this situation and drop alternating frames.
"
What frequency of data recording is acceptable, so that the data can be written to the stream without alternating?
It is possible to make it so that from RealDash it is possible to choose which IDs will be read from Can and which ones will be ignored?
I’m talking about any universal sketch managed from RealDash?
Perhaps the development of the Can2way protocol …
That would be a responsibility of sending device. RealDash just reads all can frames that are sent to it.
I suggest that you alter your Arduino code in a way that keep sent frames in memory and only send the frame to serial if any of the 8 bytes have actually changed. This will free a lot of serial resources as there are a lot of data that stay pretty much static for a long period of time.
Thanks for the tip. it is a good idea. I will find out what can be done.
Do you think that this way will slow down the display of real time?
No, it will speed it up.
This is what ordinary packages look like
and here are the error packets
I have a question: is it possible to track such packets with incorrect headers and exclude them from the air?
why do they even appear in the panel, if everything is described clearly enough in XML? (can monitor here for clarity)
Is it possible to create an option for RD CAN, in which you can enter all the necessary packets, and let the rest of the packets with unidentified IDs be ignored?
Make a frame filter, so to speak, that the user will adjust.
I still don’t understand how these “dirty frames fly” through XML? (I don’t mean the Can monitor, I’m talking about the real display on the panel, I inserted the CAN monitor for the sake of example, I understand that the XML does not work in the CAN monitor)
I understand where the glitches appear in the panel.))))
for example, there is a package ID 0x0186
The first 2 bytes are revolutions.
and after some time RealDash registers the package
with ID 0x17000186 in which the first two bytes are some kind of garbage, here’s a sharp jump in values, since RealDash will skip ID 0x17000186
because XML says skip 0x0186
which corresponds to the first bytes in a dirty ID.
I’ll definitely tell you, I need an ID byte filter,
, or somehow rigidly register all 4 bytes of the header in XML.
Is such a scenario possible? I’m right?
here is the confirmation:
now RPM = 0
what the screen says
but if you scroll below we will see the same
, only a dirty Id that I don’t have in my car, and we will see on it the value in bytes 1 and 2
, RealDash regards this as an engine speed of around 6,000. Since this ID is very rare, we will see a simple twitch of the arrow …
Hurray, I understand where these jerks come from
It remains to understand how to remove them?
I just found out that a 4-byte header can be specified in an XML file.
I registered all the headers as 0x00000xxx.
Everything is working.
I’ll ride with the redone XML, and later I will unsubscribe about the tests)))
After several days of testing, I can conclude that using a 4-byte header definitely improves data reception on the RealDash side. There is practically no interference. but unloading the sequential stream is still necessary.
So far, I have not found the correct way to automatically write all IDs for arduino to memory.
Declaring arrays for 50 different packages,
with 4 bytes of header and 8 bytes of data in each seems like an impossible task for atmega328pu.
600 bytes of memory that you need to quickly compare and overwrite when changing.
So far I’m looking for the best way.
If Jani, you tell him, will be great.
In this case I would do the following:
- On your Arduino device, make the list of CAN frames that you need to send and discard rest of the frames. Do not send CAN frame to serial if you will not need it in RealDash.
- Pick 5 CAN frames that has the least frequent data changes. Keep ‘last sent’ version of these 5 frames in memory and only send to serial if any of 8 data bytes have changed.
The main thing is that there is no point to flood all CAN frames to RealDash to burden the serial communications unless you really want to scan the entire CAN bus.
Thank.
If you send data in two directions through serial, it will slow down or it does not affect?
nevertheless, I plan to make a list of addresses on the RealDash side, and then send this list so that Arduino can make variables from this list.
My goal is a universal sketch, without constant programming.
Yes, sending data back to CAN device will slow down the connection somewhat.