Hi, i wanted to thank you for this great library, this definitively was a lot of work.
I want to reproduce the behavior of an equipment for a personal project. I bought this equipment and recorded the frames using a logic analyzer (in different scenarios but it not relevant for this topic). The first screenshot is a reference frame without any equipment connected to the car, we see the sender pulling to the recessive state, the frame is not acknowledge. As a side note the emitter detects it and send the frame again two more times.
This time the equipment I bought is connected thus it acknowledges the frame sent to it by pulling the lines to the dominant state at the end of the frame. It is detected and there is no repetition.
Finally this time the equipment is disconnected and I connected my breadboard to the VAN lines (with GND) using a 3D printed connector I made. The transceiver used is the SN65HVD230 with the resistor desoldered as for the diagram in the Readme of this repo. The code loaded on the ESP32-S3 uses the VanBusRx.Receive(pkt, &isQueueOverrun); function to receive all frames and pkt.DumpRaw(Serial); to print it. Here is a picture of the hardware.
The logic analyzer is connected via Dupont wires to the breadboard. Sadly the same frame as the first screenshot is observed : no acknowledgement. This was predictable as the code doesn't specifies which frames are intended for us.
I want to implement this feature. It has to accommodate several constraints :
- does not brake existing code which is not using this feature.
- as few modifications of the existing code as possible. It has to be easy to maintain, reusing existing interrupts, timers and functions where I can.
- responds only to the frames we want. (addresses?), and we should be able to change our criteria during the execution of the code, which means we have dedicated functions like
VanBusRx.ActiveACK(2, [0xABC, 0xDEF]); to turn it on and VanBusRx.ActiveACK(0); to turn it off.
- integrates with
AckStr() and thus DumpRaw() along with "ACK" and "NO_ACK" -> "GEN_ACK" ?
- gives back the library in a proper state after the frame has been acknowledged so following frames can be received or sent.
- and probably a lot more...
I first thought a good place to trigger the dominant state was in the void IRAM_ATTR WaitAckIsr(){} function, but I think this ISR is triggered when another equipment makes his own ack.
- is the
pkt.Iden() information available before the end of the frame ? (so we can filter what frame we need to respond to)
- can you think of an other function or ISR where I could link a timer to an ISR ?
- can you think to anything this may conflict with ?
- the architecture of the VanBusRx.cpp file is quite hard to understand, do you allow me to use Mistral AI for it to teach me how it works ?
Thank you for your attention :)
Bonne journée !
Hi, i wanted to thank you for this great library, this definitively was a lot of work.
I want to reproduce the behavior of an equipment for a personal project. I bought this equipment and recorded the frames using a logic analyzer (in different scenarios but it not relevant for this topic). The first screenshot is a reference frame without any equipment connected to the car, we see the sender pulling to the recessive state, the frame is not acknowledge. As a side note the emitter detects it and send the frame again two more times.
This time the equipment I bought is connected thus it acknowledges the frame sent to it by pulling the lines to the dominant state at the end of the frame. It is detected and there is no repetition.
Finally this time the equipment is disconnected and I connected my breadboard to the VAN lines (with GND) using a 3D printed connector I made. The transceiver used is the SN65HVD230 with the resistor desoldered as for the diagram in the Readme of this repo. The code loaded on the ESP32-S3 uses the
VanBusRx.Receive(pkt, &isQueueOverrun);function to receive all frames andpkt.DumpRaw(Serial);to print it. Here is a picture of the hardware.The logic analyzer is connected via Dupont wires to the breadboard. Sadly the same frame as the first screenshot is observed : no acknowledgement. This was predictable as the code doesn't specifies which frames are intended for us.
I want to implement this feature. It has to accommodate several constraints :
VanBusRx.ActiveACK(2, [0xABC, 0xDEF]);to turn it on andVanBusRx.ActiveACK(0);to turn it off.AckStr()and thusDumpRaw()along with "ACK" and "NO_ACK" -> "GEN_ACK" ?I first thought a good place to trigger the dominant state was in the
void IRAM_ATTR WaitAckIsr(){}function, but I think this ISR is triggered when another equipment makes his own ack.pkt.Iden()information available before the end of the frame ? (so we can filter what frame we need to respond to)Thank you for your attention :)
Bonne journée !