RomRaider

I believe validation is enabled. As long as the parser can find them we're good. I suspect it only looks in the startup dir unless told otherwise.

Ahh, OK. I'll think about that one. I think we just cross posted in here, too, might pay to check the previous page.

It used to be edited for debugging purposes but I move that option to the Logger help menu, so I believe it's mostly static now.

Great, thanks :-)

i don't know what's going on in here, but good work you two.

Its fasinating thats for sure.

What does: "Warn me when real and byte value calculations conflict" mean?

Check /romraider/src/com/romraider/maps/Table.java, validateScaling()
I don't recall what this warning is without following the logic other than to say it has to do with converting the ROM raw data (bytes, words, float etc.) to/from real numbers.

This made me LOL a little. Someone is actually doing a bogus conversion back and forward from an arbitrary floating point start point and then arbitrarily checking that it's got close enough, where close enough = 3dp of precision :-)



I'm guessing that this function is run once for every table/datafield on rom load?

Maybe these roms are more complex than I think, but the preferred solution is to be OAOO compliant and have one set of conversions that are performed forward and back. Typically you have a div/mul and an add/sub and an order of operations.

Say you have a real world value of 5 (just for instance LOL) and it's stored in a fixed point 16 bit field on the device. I'm going to say that it's 5 degrees C. And the device is working with 0.01K base units. Thus to get your device number to a real number you divide by 100, then subtract 273.15 to get C. To reverse the process you add 273.15 and then multiply by 100 and round or truncate into the integer from your floating point PC side real world unit. So for our 5C we make it 278.15 then 27815 then store it.

I should add a pair of printlns to the scaling checker and execute the app... one moment...

Yeah, subby is nothing special, it just does what I described above, but uses a fancy library to parse a textual expression instead of specifying the scale and offset:



That would be a HUGE change to convert, though, just due to the data. The code side would be pretty easy. It's also a shame that:

x*.001333224
x/.001333224

Isn't expressed as:

x/750
x*750

Which I guarantee you the subby engineers used...

Thanks for the pointer :-)

Fred.

BTW, that bogus conversion thing is at least part of the last one or so seconds of a ROM load. I was waiting for my dump and nothing nothing nothing BAM :-)

The ROM stores maps int various forms uint8, unit16, uint32, int8, int16, int32 and IEEE754.

For example 5° of timing, could be stored as uint8 data. So the ROM will actually contain 0x47 in the raw map cell.
The Table Structure that defines the Timing map will have two conversion parameters. A multiple and an offset value, which is additive.
For this example the multiplier is 0.3515625 and the offset is -20.
To get the real number (x*0.3515625)+(-20), where x= 0x47 gives 4.9609375°
To go back to uint8 (x-(-20))/0.3515625, where x= real number 5 gives 71.11111111 or 0x47.

So I guess that function is checking that the conversion is within an acceptable margin of error.

Yep, I know, I've designed my share of these from scratch :-)

The thing is, though: 0.3515625 = 1/2.844444444 = 90 / 256 << The 256 is no accident...

I absolutely guarantee you that all of these conversions started life as integers and not obscenely long, easy to screw up floating points of limited accuracy.

Therefore it's MUCH cleaner to define them as what they really are, rather than an approximation. Sure the app will turn them into dirty doubles anyway, and it doesn't matter at that point, but if they're defined as ordered discrete steps, then they can be reversed, and you only need one copy of them, and there is no need to verify them, as they are one and the same.


Yes, that's exactly what it's doing, however as I explained, this shouldn't be necessary. It's a bit of a hack. I can see the evolutionary process that caused it, though, and there isn't much to be done about that really. Kind of a shame.

The thing now is, you have a HUGE volume of data in this slightly broken format and it's not practical to convert it. I'm going to keep scratching my head over this one, though, as I absolutely won't define my stuff in this way.

Perhaps the best approach is to use multiple classes to handle conversion and data lookup. Kinda like open office saving as pdf or odt or doc. That would enable me to use YAML for my stuff too, instead of verbose XML. Time will tell, I guess :-)

Fred.

This one really feels like a stupid question....

I put the code back how it was and fired it up with a real connection. I was hoping to get a plugins menu that I could select which ever from. How do I select one of the plugins to attempt to connect to my /dev/ttyUSB0 device? I want to get something to fail first. Then I can get something to work :-)

Help a n00b out :-)

Fred.

Select your Serial port via the Plugins menu item for the External sensor you wish to use.
Without a successful ECU connection you will not see any data recorded when you select that External Sensor item to log. BUT, if you set Debug level to TRACE you should see the plugin data source manager connect (or attempt).

It was my fault, some file wasn't in the right place, building with ant works fine on a clean setup. I'll track it down and figure it out. Thanks for all of your help! Sorry that my questions are annoying :-)