Calling all MBE sufferers
Discussion
Can someone on here lay claim to the most unreliable connection from their laptop to their MBE. You know the sort of thing, you connect and then if forever disconnects and requires reconnecting.
I need someone as a guinea pig to test out some software.
I might also add its very unlikely anything will go wrong, But I also have to add I can't be responsible if someone gets the hump and presents me with a bill for a defunct ECU from a local dealers.
Edit. On re-reading this I'm not selling it very well, am I
I need someone as a guinea pig to test out some software.
I might also add its very unlikely anything will go wrong, But I also have to add I can't be responsible if someone gets the hump and presents me with a bill for a defunct ECU from a local dealers.
Edit. On re-reading this I'm not selling it very well, am I
Tanguero said:
Mine disconnects every few minutes, which is a bit of a pain. What is your fix and what does it involve? I am familiar with low level programming so I am most interested.
[Deep Breath]The communication between the ECU and the computer is flawed at a programming level. The computer has an almost unending buffer, but the ECU being a simple dual fifo single byte uses a software interrupt to store into a fourteen byte overlap buffer.
There is no hardware or software handshake and it relies on the fact that the computer will not overload its buffer, otherwise the first written will be overwritten.
The computer therefore sends pulses of fourteen bytes, then simply waits a short period of time before it sends another fourteen bytes. There is no attempt by the current software to vary the time depending on what is recieved back. In other words there is no link between transmitted commands and recieved answers in the ECU software and no software handshake coding.
Sooooo... obviously if there is a delay in your conputer interface USB dongle, or reception there is a high likelyhood that the short 'FIXED' delay put into the MBE software will fail, and the connection die.
Don't send another command till you get the reply from the first one and the fixed delay can be made variable, also improving the reiability even with USB converters.
[And Breathe]
P.S. if you're a low level coder, try and explain why
0x8016 = 0.1
0x7fd0 = -0.1
0x89fc = 7.8
0x70c5 = -11.9
I think this is memory floating point representation with MSB sign but I think I'm having a blonde moment cos its not what I'd want delivered to me if I was an MBE processor.
It certainly sounds like a gatekeeper handshake should fix the disconnects - presumably with a timeout so the software doesn't wait for ever if the ECU really doesn't reply for some reason.
Do you have something for me to test?
That doesn't look like any float encoding I am familiar with, and I can't see how it works off the top of my head. I will ask around. What is the processor in the ECU? I never got round to looking.
Do you have something for me to test?
That doesn't look like any float encoding I am familiar with, and I can't see how it works off the top of my head. I will ask around. What is the processor in the ECU? I never got round to looking.
julian64 said:
Tanguero said:
Mine disconnects every few minutes, which is a bit of a pain. What is your fix and what does it involve? I am familiar with low level programming so I am most interested.
[Deep Breath]The communication between the ECU and the computer is flawed at a programming level. The computer has an almost unending buffer, but the ECU being a simple dual fifo single byte uses a software interrupt to store into a fourteen byte overlap buffer.
There is no hardware or software handshake and it relies on the fact that the computer will not overload its buffer, otherwise the first written will be overwritten.
The computer therefore sends pulses of fourteen bytes, then simply waits a short period of time before it sends another fourteen bytes. There is no attempt by the current software to vary the time depending on what is recieved back. In other words there is no link between transmitted commands and recieved answers in the ECU software and no software handshake coding.
Sooooo... obviously if there is a delay in your conputer interface USB dongle, or reception there is a high likelyhood that the short 'FIXED' delay put into the MBE software will fail, and the connection die.
Don't send another command till you get the reply from the first one and the fixed delay can be made variable, also improving the reiability even with USB converters.
[And Breathe]
P.S. if you're a low level coder, try and explain why
0x8016 = 0.1
0x7fd0 = -0.1
0x89fc = 7.8
0x70c5 = -11.9
I think this is memory floating point representation with MSB sign but I think I'm having a blonde moment cos its not what I'd want delivered to me if I was an MBE processor.
Steve.
Steve_T said:
The fixed comms delay stuff makes sense Julian, but I recall previous threads saying avoid USB serial comms. What about trying either a PCMCIA serial card or an older refurbed laptop, with a built in serial port? Perhaps you've ruled this out already, but just a thought.
Steve.
I agree about USB serial comms being dodgy, but I still get the same problem when I use a laptop with a physical serial port. So I think the problem is not just USB.Steve.
Tanguero said:
Steve_T said:
The fixed comms delay stuff makes sense Julian, but I recall previous threads saying avoid USB serial comms. What about trying either a PCMCIA serial card or an older refurbed laptop, with a built in serial port? Perhaps you've ruled this out already, but just a thought.
Steve.
I agree about USB serial comms being dodgy, but I still get the same problem when I use a laptop with a physical serial port. So I think the problem is not just USB.Steve.
Therefore anything which interferes with the timing such as the delay across a USB, textencoding by the serial port or even the operating system taking interrupt priority from the port. So probably get away with it in DOS win98 etc not sure about ME.
The software was written for a software operating system that didn't interrupt the port flow. More modern operating systems require the software to be written time tollerant or using handshaking. Xp or above
julian64 said:
Processor is an 80196KC intel jobbie. So old that I'm having trouble finding a half decent disassembler/simulator for it. 
Have you had a look at Python's Project-96?Tanguero said:
julian64 said:
Processor is an 80196KC intel jobbie. So old that I'm having trouble finding a half decent disassembler/simulator for it.
Have you had a look at Python's Project-96?IDA is a reasonable disassembler but not a debugger, but no disassembly from IDA will get close to a decent compile in phyton. Its like another planet. There must be something better out there.
Tanguero said:
That does sound a bit pants! I will keep an eye open for anything else.
In the meantime was there some software you wanted me to test? I think my connection is sufficiently unstable to present a reasonably good test case.
Super, could you email me a real email address as I believe you can't send attachments through PH. In the meantime was there some software you wanted me to test? I think my connection is sufficiently unstable to present a reasonably good test case.
P.S. as its development could you let me know the com port you will be using so I don't have to code for a search and choose
The MBE is a remarkably versatile piece of kit. There is a lot of unused pins/ports drivers and a good bit of spare processor time. Nothings gone wrong with my car recently (touch wood) so I'm concentrating on the MBE.
In the world in which we live the MBE is ideal for a Cerbera because it came before manufacturers really started using protected code software.
All the later MBE stuff is protected.
In other words the MBE941 is the last truly open source control system for a car.
The only problem is that someone lost the source. Or at least didn't release it.
If we as a group manage to recreate an understanding of the source code then an eprom change is all you'll need to have:
A fully on the fly mappable engine management system with ignition injection and timing all at your disposal, for track or MOT. Accessible by your PDA from the drivers seat.
The chance to add a few cheap maplin sensors wired to the MBE
and get traction control or ABS (fuel or ignition mediated)
A single antiknock sensor bolted to your engine would monitor all the cylinders.
A completely foolproof alarm system.
A fuel flow meter giving you minute by minute consumption, and more importantly a guide to how far you can go without running out of fuel.
A few G sensors would make you into a track gizmologist and track data mapping.
A futuristic projection screen display
Or my personal favourite, a nodding dog siting in the back window that stuck a finger in the air automatically when your fuel consumption went below 10mpg.
To be honest whether you did any of that, something different, or none of it. I just want to be able to say I could if I wanted to.
I reckon I'm currently three months in, and about six months from being able to do the mapping bit if nothing jumps out and surprises me.
In the world in which we live the MBE is ideal for a Cerbera because it came before manufacturers really started using protected code software.
All the later MBE stuff is protected.
In other words the MBE941 is the last truly open source control system for a car.
The only problem is that someone lost the source.
Or at least didn't release it.If we as a group manage to recreate an understanding of the source code then an eprom change is all you'll need to have:
A fully on the fly mappable engine management system with ignition injection and timing all at your disposal, for track or MOT. Accessible by your PDA from the drivers seat.
The chance to add a few cheap maplin sensors wired to the MBE
and get traction control or ABS (fuel or ignition mediated)
A single antiknock sensor bolted to your engine would monitor all the cylinders.
A completely foolproof alarm system.
A fuel flow meter giving you minute by minute consumption, and more importantly a guide to how far you can go without running out of fuel.
A few G sensors would make you into a track gizmologist and track data mapping.
A futuristic projection screen display
Or my personal favourite, a nodding dog siting in the back window that stuck a finger in the air automatically when your fuel consumption went below 10mpg.
To be honest whether you did any of that, something different, or none of it. I just want to be able to say I could if I wanted to.
I reckon I'm currently three months in, and about six months from being able to do the mapping bit if nothing jumps out and surprises me.
but how many of us here can understand such low level programming? is it written in some form of assembler or was it actually written in a higher level language and cross-compiled and burnt to the chip?
in theory it is possible to get an understanding of the code and then port it to a higher language to make it easier to add features and tweaks.
its been years, sorry, decades since i've played with anything like that, but i am very curious....i wouldn't mind helping, but i'm not too sure how much time i can dedicate to it
in theory it is possible to get an understanding of the code and then port it to a higher language to make it easier to add features and tweaks.
its been years, sorry, decades since i've played with anything like that, but i am very curious....i wouldn't mind helping, but i'm not too sure how much time i can dedicate to it
Looking at the disassembled code I reckon it was cross compiled from C
Both Julian and I have disassembled it and Julian was starting to comment the disassembly
I've successfully had the disassembled code running in a software simulator but I didn't add any input/output stuff so it was just sat there as it would with the ignition on but no start button pressed.
In theory it should be possible to work through the disassembly and abstract it back to a higher level representation.
I'm not going to bother because my ECU is early 98 and the later code produces a better base to start from (it actually runs in the simulator whereas the code from the chip in my ECU won't)
What I will do at some point is work out whether or not the mythical aircon control from the ECU does actually exist
But I probably ought to finish cleaning up and painting the chassis first (and putting the front suspension back on, and the steering rack, and the radiator and hoses, and the aircon .....
Think I got a bit carried away
Both Julian and I have disassembled it and Julian was starting to comment the disassembly
I've successfully had the disassembled code running in a software simulator but I didn't add any input/output stuff so it was just sat there as it would with the ignition on but no start button pressed.
In theory it should be possible to work through the disassembly and abstract it back to a higher level representation.
I'm not going to bother because my ECU is early 98 and the later code produces a better base to start from (it actually runs in the simulator whereas the code from the chip in my ECU won't)
What I will do at some point is work out whether or not the mythical aircon control from the ECU does actually exist
But I probably ought to finish cleaning up and painting the chassis first (and putting the front suspension back on, and the steering rack, and the radiator and hoses, and the aircon .....
Think I got a bit carried away
Edited by mikesr on Friday 14th December 20:14
Gassing Station | Cerbera | Top of Page | What's New | My Stuff