MEVD17.2 emulation in development
- Thread starter LamboLover
- Start date
It is a multiplatform interface, just trying to get the basics going on all the comms layers by testing each part hard as I go. The ECU is ready to run very fast logging, it would be a case of sending the RAM addresses to log to it and processing the stuff returned. I didn't do it with J2534/TunerProRT as they are really setup for single rate logging whereas the ECU sends at 350 Hz, 100Hz and 10Hz. If I get the microcontroller to reassemble them and create a logging row it should jive well with how TunerProRT likes its data.
https://www.amazon.com/gp/product/B07D6Y3GN2/ Isn't this tool similar to what you built?
I am planning to add K-CAN and PT-CAN pins into OBD2 socket and read them there. Is that how you did it for the logging, btw ?
I am planning to add K-CAN and PT-CAN pins into OBD2 socket and read them there. Is that how you did it for the logging, btw ?
That looks like a nice device, reasonably priced. The usual problem is that the firmware and CPU is not fast enough, but if it is actually J2534 compliant it should be very good. The problem is that a lot of J2534 stuff doesn't stick to the specs. The gateway already has CAN H and L, so you can use them for KWP2000 on CAN through the OBD port. It won't give you all the stuff that is transmitted on PT-CAN but you can request what you want. Edit - the CPU does look good although the one I'm using is 5 times faster and has 16 times the flash memory. Sources are on Github too so that is promising to tweak it to your needs.
Last edited:
Ah, I love it when good hardware is used. Who likes 'base model' electronics anyway
Added BMW specific TCP comms format to do the above with extended addressing to suit KWP over CAN and UDS over CAN, with backward compatibility for K line (not yet implemented but part of the hardware design), support for 4095 byte UDS frames (16 times bigger than present 8 bit DCAN cables with consequent massive increase in performance). Performance is close to Ethernet, but this is using CAN which has a far wider audience.
Made J2534 driver for plain CAN frames to satisfy one of the original purposes of a new physical device: to allow realtime tuning without having to buy in expensive J2534 cables. This works over WiFi, performance is in between the Kvaser and OpenPort 2.0 USB cables you can see in the selection window above. Both of these are $200-300 and the cheapest good J2534 devices - the Chinese copies are unreliable and slow.
I have four prototype OBD devices stuck in customs. These have a different internal physical arrangement to join the two boards together to fit in the small enclosure. They also have 16MB external flash, but subsequent revisions will have this on the module itself and will have 4MB external RAM instead of existing 512KB which is enough to play DOOM (no display included
), or hold a flash image to operate on in one session. Doesn't sound much, but a recent DCAN solution has 3.5KB of RAM.The only testing done by the electronic engineer is to see they do not let out smoke and throw some stuff out on serial when powered, so lots of functional testing to do, but very exciting seeing it come together.
Last edited:
Prototypes arrived Thursday, but they were untested and had hardware problems. New designs done and ordered and the electronic engineer will test this time.
The firmware for this is a huge task so I had arranged an expert to do the layout so I could concentrate on firmware.
Let's hope the expert delivers this time.
The firmware for this is a huge task so I had arranged an expert to do the layout so I could concentrate on firmware.
Let's hope the expert delivers this time.
Lots more work on firmware going well. Simultaneous BMW KWP/UDS over CAN on one port with CCP on another port for realtime tuning and logging.
Got two of the prototypes of the old design working - the problem was hole size and position between header board and main board. Soldering fixed it, but it took some finding.
One board I have configured using external 16MB flash, the other with 4MB internal flash. The external flash runs in dual instead of quad SPI mode for some reason, but it is likely we will be using modules with 16MB internal in production.
Got two of the prototypes of the old design working - the problem was hole size and position between header board and main board. Soldering fixed it, but it took some finding.
One board I have configured using external 16MB flash, the other with 4MB internal flash. The external flash runs in dual instead of quad SPI mode for some reason, but it is likely we will be using modules with 16MB internal in production.
WiFi flashing is working hilariously fast.
New test boards.
New test boards.
Lots of testing of the new boards since I got them yesterday. One layout has superior antenna performance. Today have tested flashing of the device, then using it to flash a DME, flex fuel input including five different filtering options. Yesterday I added some K line line test code that works for loop back once I realised I had to invert the UART TX line for using a FET to pull the K line low. I think I will have the pull up resistor for flex fuel at the sensor itself since then it can be pulled up to switched 12V as there is only permanent 12V in the OBD port. Saves quiescent current if it was pulled up to 3.3V through 3K, and pull up to 12V in use will give better noise immunity. The plan with this version is to add a pin to the unused L line and use this for the flex fuel sensor.
Last edited:
Got the device to work as accesspoint and station on two simultaneous WiFi networks, as long as the PC does not use Intel Centrino wireless oddly. Broadcom wireless works, as does Android.
So this means you could stay connected to the OBD wifi dongle as well as your home/hotspot wifi?
