On 2014-10-08 12:27, Dirk Hohndel wrote:
On Tue, Oct 07, 2014 at 09:09:35PM +0200, Jef Driesen wrote:
On 02-10-14 19:49, Dirk Hohndel wrote: So I would like to already go ahead and apply the other patches:
Patch #3 and #4 look good to me. As explained before, the DTR/RTS shouldn't cause any problems for other devices, because if it did I would already had received plenty of bug reports from Windows users. One minor issues is that I'm pretty sure the rb_profile_end field of the layout is actually 0x3FE00 instead of 0x40000. That's why I asked you for a full memory dump.
Sorry, busy flying to Bonaire and diving.
For patch #5, where did you get the density value 1003 from? According to your patch, only the water type is stored in the data, but not the density. Since this is optional value, maybe we better leave this as zero?
OK
I have attached a slightly modified versions of your four patches. If you're happy with the changes I made, I'll push them already to the master branch.
Patch #6 is the only one where I don't understand the logic. Are they really using this very weird encoding, or are we missing something? Am I correct that if only 1,2,3 or 4 tanks are enabled, these are always the first ones?
I spent an evening playing with the simulator and their app. Trying every single value this is the logic that I found. I think it would be a nice feature not to get the unused tanks, but my confidence that this is 100% correct is not 100% :-/. The problem is... the only way to get this more widely tested is to add the code and wait if it works as expected in all circumstances.
Does that mean you found the trick to make the Aeris application talk to the simulator? Can you share what you did, because I had so success so far.
I think I found the logic. Look at the three relevant bits:
001 -> 1 011 -> 1 101 -> 1 111 -> 1 010 -> 2 110 -> 2 100 -> 3 000 -> 4
There is clearly a pattern here. All 4 combinations that map to one tank have the lowest bit set. With two tanks, the second bit is set. And so on. Thus this code should do the trick:
if (data[0x39] & 0x04) { *((unsigned int *) value) = 1; } else if (data[0x39] & 0x08) { *((unsigned int *) value) = 2; } else if (data[0x39] & 0x10) { *((unsigned int *) value) = 3; } else { *((unsigned int *) value) = 4; }
I included this change already in the attached patches.
Originally I was puzzled by the fact that there are multiple ways to encode some values. And that makes no sense at all. But then I realized you probably made up data with the simulator to try all possible bit patterns. I guess that in real data, we'll only see these 4 bit patterns:
001 -> 1 010 -> 2 100 -> 3 000 -> 4
Jef