arduino-CAN
arduino-CAN copied to clipboard
sandeepmistry
Same packet received over and over (ESP32 and 500Kbps vehicle bus)
Tried the basic receive example after trying the OBD keystats example with no success.
Seems to be getting valid data from the bus - but keeps printing the same packet over and over. Same ID, same packet data. Like the buffer is not being cleared?
I have been able to duplicate this - seems to happen when the bus load is high - cangen can0 -g 3 from a raspberry pi to the ESP32 seems to cause the issue. 5 ms packet gap is stable.
I have been able to duplicate this - seems to happen when the bus load is high - cangen can0 -g 3 from a raspberry pi to the ESP32 seems to cause the issue. 5 ms packet gap is stable.
i am also having the same problem. basically my device device was running properly around 8 hrs after that i am keep on getting same msg in can receiver side and it never stops. Did you find the solution?
Never really fixed it - kept my project from being finished. I'll dig into this again maybe over the December break.
Same here. Using a SN65HVD230 module, built in 120ohm termination, Rs=10k sets the chip to slope control. Might have a go at replacing the 10k with a short to ground to put the module in high speed mode. EMI is not a concern for just listening anyway.
Did you ever figure this out? I'm having exactly the same problem. Did shorting pin 8 to ground for high speed mode help?
Did you ever figure this out? I'm having exactly the same problem. Did shorting pin 8 to ground for high speed mode help?
I used a 10ms delay in the loop to prevent the loop from reading the same package twice.
It's better to use micros rather than delay, but delay will also work
I suggest checking the code of the library and comparing what it does to the data sheet. I did this for the MCP2515 implementation and found numerous mistakes where the code clearly wasn't following what the data sheet said. Perhaps the same is true about the ESP32 implementation.
The whole code that deals with registers when receiving data in the ESP32 implementation is less than 40 lines, shouldn't be too hard?
try this
`#include <Arduino.h> //#include <mcp_can.h> //#include <mcp_can_dfs.h> #include <CAN.h> #define CANint 2 #define LED2 8 #define LED3 7
unsigned char len = 0; unsigned char buf[8]; unsigned long ID = 0; unsigned long line = 0;
//MCP_CAN CAN0(17); // Set CS to pin 17
unsigned long time; void setup() { Serial.begin(115200);
while (!Serial) { Serial.print("I will wait here forever..."); delay(1000); };
pinMode(23, OUTPUT); digitalWrite(23, HIGH);
pinMode(LED2, OUTPUT); pinMode(LED3, OUTPUT); pinMode(CANint, INPUT); digitalWrite(LED2, LOW);
Serial.println("CAN init:");
if (CAN0.begin(CAN_250KBPS) == CAN_OK) { Serial.println("Can Init Success"); } else { Serial.println("Can Init Failed"); while (1) { Serial.print("I will wait here forever..."); delay(1000); } }
Serial.println("Good to go!"); }
void loop() { time = millis();
if(CAN_MSGAVAIL == CAN0.checkReceive() && line < 10000) { // Check to see whether data is read CAN0.readMsgBufID(&ID, &len, buf); // Read data
//Add this line back in if you want to filter traffic if(ID == 1201) { //39 line = line + 1;
Serial.print(ID,HEX); // Output HEX Header
Serial.print("\t");
for(int i = 0; i<len; i++) { // Output 8 Bytes of data in Dec
Serial.print(buf[i]);
Serial.print("\t");
}
Serial.print(time); // Timestamp
Serial.print("\t");
Serial.println(line); // Line Number
// } } delay(10); }`
I strongly suggest not trying to "fix" bugs by adding delays.
It's not going to fix anything, it will only make the issue less likely to happen.
The issue will still happen, possibly when you least expect it.
Since we're talking about a library with automotive applications, I don't think that's good enough.
I strongly suggest not trying to "fix" bugs by adding
delays. It's not going to fix anything, it will only make the issue less likely to happen. The issue will still happen, possibly when you least expect it. Since we're talking about a library with automotive applications, I don't think that's good enough.
The delay is because the esp32 scan cycle is much faster than the comms update rate , so it reads the same package in multiple scans. Delay is an easy way, best way as I said earlier is to use micros so to chose how often to read.
On the other hand this are diy project mostly that we only read not write to the canbus , so I can't see any harm
esp32 scan cycle is much faster than the comms update rate , so it reads the same package in multiple scans.
A correct implementation of the protocol should set appropriate registers in such a way that if you query the data too often you receive "no new data" instead of duplicate data.
On the other hand this are diy project mostly that we only read not write to the canbus , so I can't see any harm
Maybe you don't write to the bus in your project, but the library allows writing data into the bus. Chances are, someone will write into the bus some day using this library.
In one of my experiments, I tried writing into the bus a bit. But first I triple-checked the relevant code in MCP2515Class and fixed bugs to the best of my understanding of the data sheet.
