Yeah, correct
You got the idea.... For now, this should get you going with storing neg values until a permanent fix is found.
I'll try to patch later today.
If you're bored and want to understand more about what Roberto was talking about, try this: http://en.wikipedia.org/wiki/Two%27s_complement
Signed ints are stored using "twos complement notation" inside the arduino. You'll see a little table on the right hand side toward the top of the page, illustrating storage of positive and negative numbers (although in 8-bit format rather than 16 like your situation).
Current setup:
60g 24" custom cube (fish and softies right now)
AI Sol Blue, Ecotech MP-10wES
Coralife skimmer
100% customer controller, transitioning to ReefAngel
I understand two's compliment and how large numbers are stored in binary representations. I guess the issue for me is that we are storing int's and bytes which are made up of multiple bits. We aren't flipping bits one by one we are doing write() and write_int() one byte at a time. I guess the bigger problem is that from the web we are writing one character at a time and assuming its a digit and dropping non-digits. So the negative is being treated as garbage and being dropped on the floor.
In the case of a /mb request or /mi request we should not drop it on the floor but instead set the signed bit accordingly...
I've got a working front-end storing the value appropriately, but it would simplify a lot if we just did it correctly on the back end.
I would argue that, in the long run, end-user apps shouldn't be worrying about bytes and ints at all.
Hopefully in a week or so I'll have something to show for how I envision this working.
I must admit I still haven't figured out where the params in the request are actually parsed from ascii to byte values... (where is "weboption" set?)
Current setup:
60g 24" custom cube (fish and softies right now)
AI Sol Blue, Ecotech MP-10wES
Coralife skimmer
100% customer controller, transitioning to ReefAngel
enigma32 wrote:I would argue that, in the long run, end-user apps shouldn't be worrying about bytes and ints at all.
Hopefully in a week or so I'll have something to show for how I envision this working.
This should be good. I look forward to seeing this.
I must admit I still haven't figured out where the params in the request are actually parsed from ascii to byte values... (where is "weboption" set?)
weboption is set in the ELSE clause inside the pushbuffer function.
I have successfully patched /mr to take two variables to read a custom range in memory. If for some reason the start number is higher than the end number, it returns ERR.
This code should be added to the html output so that the new /wifi page can fit the display on the phone. It scales great if you double click the page, but this would set it to be default.
It was already there... It didn't have the min, max and user define, but was there. I added the other ones. Check if it scales now.
On my android, it scales on height, not on width.
Actually it may be worse now.... I cant scale it all now on safari. Not sure what it was like before. I was using chrome in previous tests. Also data loading fine in safari so maybe a chrome issue..
This is what I got:
Viewport argument value "device-width;" for key "width" is invalid, and has been ignored. Note that ';' is not a separator in viewport values. The list should be comma-separated.
My original code had comma and when you posted yours, I changed to semi-colon.
So, I updated once again back with a comma. Can you see if it does it now?
14-Radion - Blue Channel
15-Radion - Green Channel
These are reversed in practice... When I set the po14,0 it changed the RFG and when I set po15,0 it changed RFB.
A bit off topic but the reason for this discovery... something is changing my RFB and RFI to 100 and I can't figure it out. I have nothing in my code that references the Radion's at all, except that I'm using the Custom mode for the Vortech... I did have 100 in Mem_B_RadionRadionSlopeEndB and Mem_B_RadionRadionSlopeEndI but I corrected that. Then I overrode the channels to 0 and put back to default and it went right back to 100. It's happened a few times and not sure what's triggering it. Any thoughts?
Thanks!!
What you are getting is the intended result. It was a mistake on that post. I corrected it.
It has to be something within your code.
It is not the override as you can see it in here: http://forum.reefangel.com/status/chart ... filter=rfb
Can you open a new thread?
Hamid2 wrote:I have the same question, is there a schema for the data that /sr or /sa will return? The answer to genuflect is begged!!
If you want to know what the schema looks like, then you need to view the code. It's located in the RA_Wifi/RA_Wifi.cpp file. Here's a link to the github location of the file: https://github.com/reefangel/Libraries/ ... A_Wifi.cpp
Around line 300, there will be a line that says "case REQ_R_STATUS:"
That section shows the the XML code that is generated by those 2 commands.