ROMulator connection issues

bemis · Post by **bemis** » Mon Jul 27, 2009 3:18 am

This maybe a hardware or software related issue, but I'm having some connectivity problems with ROMulator, NIStune, and the laptop. Given the set conditions:

ROMulator ON
Emulator box in NIStune ON
BIN uploaded
Engine ON
Infiniti M30 ECCS

Whenever I make changes to the BIN in realtime, 75% of the time the ROMulator disconnects from NIStune and the change is not written. I have to reconnect to the ROMulator and try to apply the change again. Sometimes I have to do this a couple times before the change takes affect. I've noticed that there is a higher probably of connection failure when CONSULT is connected. I have no problem what so ever uploading the entire BIN to the ROMulator and thats usually what I do everytime I want to make a change just to avoid the connectivity issues. Let me know what you think.

-bemis

Matt · Post by **Matt** » Mon Jul 27, 2009 1:11 pm

running latest version of beta Nistune with these issues? I'll put it on my list to investigate this week

bemis · Post by **bemis** » Tue Jul 28, 2009 11:17 am

Yes, I installed the latest yesterday before taking the car out for a highway tune. I should note that I've had this problem with all releases.

-bemis

Matt · Post by **Matt** » Tue Jul 28, 2009 11:26 am

no problems, I'll dig up the romulator and try it again

I dont like that unit much compared to the Moates because always having it dropout etc and seems to be more hardware related. Moates in comparison is just stable

Are you using USB serial converter with it?

bemis · Post by **bemis** » Wed Jul 29, 2009 12:20 am

Yes, I'm using a Dual Port Serial to USB convertor. I also have my LM-1 connected through the convertor. There doesn't appear to be any problems with connectivity between the LM-1 and Nistune. Although with Nistune connected to the ROMulator, the LM-1, and Consult all at once the laptops processing speed really, really slows down. Thats probably the laptop fault, since it is an oldie.

Matt · Post by **Matt** » Wed Jul 29, 2009 12:43 am

whats the speed of the laptop? ive got a couple of older machines kicking around. speed of two serial connections should still work

Matt · Post by **Matt** » Thu Jul 30, 2009 2:56 am

Now remembering what this issue is... the Pocket Romulator does not do write behind emulation properly

It was never noticed with LiveEdit or Romulator software because most likely consult wasnt connected at the same time, and also changes were slow to the emulator, unlike Nistune which can buffer changes and stream them quickly

What happens is that since write behind doesnt work properly, quick successions of changes result in the ECU falling over and restarting

This happens because the emulator is controlling lines whilst the ECU is trying to read them

We use the exact same code for Moates (since they use the same protocol) and we dont see these issues with write behind

You can only really make small changes (one cell at a time and not too quickly) for the ecu not to fall over because of this. Not much I can do since the Romulator guys have a problem with their firmware which is why maptracing will never work on their hardware for Nissans

Nissans control OE and CE lines differently on various ECUs and the romulator needs to deal with both

I've seen this and its frustrating and more noticeable on some ECUs like Z32 for instance. I've supported it best that I can but theres no software fix to make it any better, apart from disabling mulitple fast writes to the emulator

Matt · Post by **Matt** » Thu Jul 30, 2009 3:13 am

just checking the intronidc site

they use
0x77 + #of bytes + [address MSB LSB] + bytes + checksum

sndbuffer[j++] = (char)ROMULATOR_CMD_WRITE_HIDDEN; // Write hidden 'w'
sndbuffer[j++] = (char)0x01; // 1 byte
sndbuffer[j++] = (param1 >>

& 0xff;
sndbuffer[j++] = (param1 & 0xff);
sndbuffer[j++] = snddata[0]; // 1 byte data
sndbuffer[j++] = com.GetByteArrayChksum((BYTE*)sndbuffer, j);

we send this and wait for completion before next byte is sent

they mention if the byte is not written after 100us then a forced write will occur. I suspect that could be happening perhaps?

I can try more experimentation. Seems to be more obvious on Z32 ECUs than earlier Z31 ecus

bemis · Post by **bemis** » Wed Aug 05, 2009 1:40 am

The laptop uses an Intel 1.13Ghz, 256MB RAM, Windows XP. The software has stripped down to bare essentials to reduce processor workload and caching. Yeah, the ram size sucks though.

Would this problem disappear with a Moates Emulator? I have to give this Romulator back to a friend eventually and I would like to have one for myself. From what I understand, the Moates unit is better suited for these applications such as the Type 2 ECCC's: Z32, Infiniti M30 + J30...

Matt · Post by **Matt** » Wed Aug 05, 2009 2:33 am

Honestly the moates units are a lot better. They now have hardware maptracing (which we support) also in the Ostrich 2.0 units. Craig also provides excellent support for his products (like when we were having problems with the Q45 VH45 ECUs)

I can see why romulator is frustrating on the Z32/M30 ECU. I'll have to find live edit and try that out with this one and see if that does the same thing.

This isnt noticable on the R31/Z31 ECUs from memory but they only use the /CE line but the Z32 uses both /CE and /OE lines which I think the romulator doesnt cope with