The problem was that the datalogger requires some additional control codes and length information for the text to be written. Unsoundcode had already mentioned it.
·· Success! The data now writes to the USB flash drive! It appears like this:
1, 263, 223
2, 262, 223
3, 262, 222
4, 261, 221
5, 260, 220, etc, etc for·whatever·NumSamples
When I breathe gently across the sensor the second number changes relatively fast. I suspect the second number is humidity.
How do we go about changing the "200's data" (above)·to readable degrees and percent humidity? I see in the sample program for the SHT11 humidity/temperature sensor that there are some conversions in the program code. They appear to be the same, or very similar,·to those in your program, but in a different sequence(?)
I tried adding Unsoundcode's 'fix' yesterday but was uncertain exactly where it went (sorry, Unsoundcode. Stick with us!)·You got the Datalogger to actually log data! We're almost there. Now, how·do we·get the data to output in readable, recognizable units (degrees and percent humidity??)
Thanks again, Mike, and everyone.·You're geniuses!· We appreciate your help more than you can imagine, and we look forward to your replies.
The data on the flash drive consists of two numbers per line separated by a comma. The first should be the temperature in tenths of a degree Celsius and the second should be the adjusted humidity in tenths of a percent. The debug window output includes a sample number as the first value. If you want the decimal points explicitly shown, try using this slightly modified from Unsoundcode:
With the two numbers on one line separated by a comma, you should be able to read this file into Excel for analysis including graphing. It's what is known as Comma Separated Values (CSV).
Post Edited (Mike Green) : 1/31/2008 4:50:17 AM GMT
We replaced these lines as suggested:
DEBUG DEC counter,", ",DEC tC,", ",DEC rHLin,CR,LF
SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 tC, ",", DEC5 rHLin, CR, LF, CR]
With the code you posted, in this order:
DEBUG "#",counter," ",DEC3 tC/10,".",DEC1 tC//10,", ",DEC3 rHLin/10,".",DEC1 rHLin//10,CR,LF
SEROUT TX\CTS, Baud, [noparse][[/noparse]$8,$20,0,0,0,13,CR,DEC3 (tC/10),".", DEC1 tC//10,",",DEC3 (rhLin/10),".",DEC1 rhLin//10,CR,LF,CR]
But we get an ‘EEPROM FULL’ error…
Question 1: Does ‘EEPROM FULL” mean that one of the two lines of new code is “full”? (If not, what does it mean?)
Question 2: Did I replace the correct lines of code?
Question 3: How do we resolve it?
Hi Mark, the program has become to large for the EEprom. Comment out the Debug instruction and see if you get the same error. There might be other ways to trim the code down, try the debug for right now.
·· I'm not sure what "commenting out the Debug instruction means." I believe it means to delete any extra text associated with the program command line. But I'm not sure what to delete, or where. Thanks for your post! Standing by...
Any line which begins with a single apostrophe is taken to be a comment. So too anything after a single apostrophe on a line which contains operational instructions (commands). Here is an example of the former using a DEBUG command as the example:
Present Line for Debugging -
DEBUG "Program is starting"
Change that line to a comment -
'DEBUG "Program is starting"
The first is executed as a command, and the second is ignored as a comment.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
Hi Mark, if you place an apostrophe ( ' ) at the beggining of a line text it can be used as a comment or description of something that is happening without it actually being included in the code. It helps others follow what your code is doing or serves as a reminder for you at some later date.
It can also be used at the start of a line of code you dont want to download but dont want to delete right away, the apostrophe virtually removes the code from the program with one keystroke and replaces, if wanted, with another keystroke.
Trying to see just how full the EEPROM was I suggested "commenting" out this line
Yes, thanks. I saw that when I placed an apostrophe ' in front of a line command it was changed to a comment. I also deleted some of the extra words insode previous DEBUG command quotes (e.g. DEBUG "The program is in the process of starting" was simplified to "Start program". This freed up EEPROM space and the program now runs.
scatter the data all the screen, though, and even on top of the text when the program runs. How do we get the data the 'print out' in neat rows as before, without any extra 0's in front of the data (25.6 degrees instead of 00256)?
Thanks so much for your valuable time, your replies, and for sharing your wealth of expertise with us. Slowly, we're learning the 'basics' (pun intended!)
Without the DEC, the value of counter is sent as a byte to the PC where it does odd things to the debug window display.
The above changes remove the leading zeroes from the numbers. Also, by putting DEC in front of counter, it avoids the messages
from getting scattered all over the debug window. In the case of the memory stick file data, you can't do the same thing since there
always has to be the same number of characters per line. It would be possible to substitute spaces for the leading zeroes, but that
complicates an already large program and, if you use something like Excel to read in the data for analysis, the leading zeroes won't
matter.
By eliminating the leading zeros in the debug display, the data may not line up any more. Again, that's fixable, but would make the
program bigger.
Hello everybody,
I'm on Mr. Kibler's (Mark in NH) rocketry team. I have been following along with all of you in the forum. I've made all of the same changes to the "RocketRobotProgram" that you have all been making. When I downloaded the program to my board and open up a debug window, it gets up to the point of "Acessing..." and it just hangs there. Is there something I did wrong or need to do? If someone could post the most recent version of "RocketRobotProgram", that would be great. Thanks in advance,
Andrew
Andrew,
Mr. Kibler should have the most recent version. I posted a version on 1/29 and there have been some corrections since then described in this thread that you would have to apply.
Mr. Green,
Thank you for your quick response. I've just downloaded and read the VDAP Firmware Manual. Like Mr. Kibler, I do not have a lot of programming experience in this language. What exactly should I do once I get the most recent version of "RocketRobotProgram". Should I re-format my drive, maybe? Thanks,
Andrew
Andrew,
The first question is "what has worked so far?". Are you working with the same hardware as Mr. Kibler? If not, you should start there and make sure your hardware setup is identical to the one that Mr. Kibler was using. It sounded like the program had worked with the Datalogger, recording data on a file. Is that not so? If it has never fully worked, what really did happen earlier? Before you do anything further, you really need to find out what has happened before and communicate that here.
One of the most basic ideas of programming and debugging is thinking (in an orderly fashion), understanding (what you're trying to do, what has been done before, and what is actually being attempted now), and communicating (to others).
Mr. Green,
I am using the same exact hardware and setup as Mr. Kibler. I am also able to use the sample program with the data logger to record random numbers, but not using the same USB drive as I am currently trying to use.
Andrew
Clearly there is something about the USB drive. There are two different commonly used formatting systems: FAT16 and FAT32 (File Allocation Table 16 or 32). Make sure the drive is formatted with FAT16 (or just FAT) format. I think the Datalogger can handle both, but I'm not sure. FAT16 is the older standard and is a little simpler. It's more widely used at present.
·· Mr. Kibler here. Just so everyone is on the same page, we are all using the same set up: Parallax 'Board of Education', Sensirion hundity/temperature sensor, and a Parallax Flash Stick Datalogger.
Andrew, I'll e-mail you the most recently updated program that everyone on the forum has helped write. Be sure to thank them profusely because they've been very patience, and very generous with their time and expertise.·The program·works really well now, with just a few minor 'bugs' to work out. You, Tim, and Tyler·should be working independently, then as a project team during practice to do this.
Once I e-mail you the newest working program, paste and save·it into a Parallax BS2 file, then start 'debugging'. I would suggest that you start with this recent post in the forum, but certainly read and·use them all. Again, be sure to thank everyone on the forum as they guide as through the fun and challenging lesson of learning progarm language. Thanks, guys!
Mr. Green,
When I tried formatting the flash drive as a FAT with an allocation table of 16, I got an error message that stated, "The cluster size is too big for the current drive. When I tried formatting it as a FAT with an allocation table of 32, I got the same error. My drive is an Imation 64MB and I tried to format it using my laptop running Windows Vista. Is there a problem with the drive, or my computer? Or is it just how I am trying to format it (using the disk management program included with vista).
Thanks in advance,
Andrew
These days a 64MB drive is small. The 64MB is divided up into 65536 or fewer clusters, but a lot of formatting programs won't allow you to format a drive with a small number of clusters. With a cluster size of 16KB, you'll have only 4096 clusters. With a cluster size of 32KB, you'll have only 2048 clusters. I suggest you use an allocation table size (cluster size) of 2KB or 4KB at most.
You probably will do better with a larger flash drive. I've seen 1GB drives for as little as $10 in the last few months. I use Windows XP which seems to use a default cluster size of 16KB with a 1GB drive.
Mr. Green,
I do agree my drive is quite small. It is so amazing how the price of flash drives have been dropping over the years. I guess I'll end up getting a new one. Do you have any suggestions for flash drives that you think would be suitable for my project.
Thanks,
Andrew
Andrew,
I suggest you try formatting your drive with a smaller cluster size first. If that works, try it with the Datalogger.
If you can't get the 64MB drive to work, see if you can get a "generic" 1GB flash drive. Radio Shack has 512MB
and 1GB USB flash drives for $5 to $15. You shouldn't have to pay more than $20. Best Buy should have similar
prices.
Mr. Green,
I'll try your advice. If I can't get my 64MB drive working, I'll probably end up buying a new one. I'll let you know how things work out. Thanks again,
Andrew
Andrew,
You could also see if your local Radio Shack or Best Buy would contribute a 1GB flash drive to your project, then have your teacher and the students on the project send a thank you note both to the local store and the national corporate office.
The question of formatting is interesting to me and something I have asked for feedback on in the past. I have had memory sticks that either don't work from day 1 and others that seem to work ok until they reach a certain point in the write cycle.
I started formatting the memory sticks Fat 32 with an allocation unit size of 512 bytes and so far have had no problems in that format with the logger. I don't know why I just know it works for me. I wondered if anyone had any comments that might help me understand why 512 is a "magic" number. This is not just a problem with small drives, it works with a Lexar 64M, PNY 1G, Sandisk 1G, and a PQI 1G.
That is only important if you need to conserve eeprom space to fit more program.
On this flight, you are quite likely to encounter negative Celsius temperatures, and the above debug code will not display them correctly. Here is wide-range display code.
To explain, the REP modifier causes a REPetition of the "-" sign either zero or one time, depending on bit 15 of the tC variable. That is the sign bit. It is 1 for negative, 0 for positive or zero. Then comes the DECimal value of the ABSolute value of tC. In the Stamp, division like tC/10 or tC//10 do not work correctly on negative numbers (in the Stamp, negative numbers are in a form called "twos complement", but the Stamp has very limited capability to do math with the negatives).
You would also need to do a similar thing in the output to the flash drive, except with consideration for the fixed field lengths.
This takes care of the sign in a different way, to allow for the fixed field requirement. Here it puts either a space (asciii value =32) or a minus sign (ascii value = 45 = 32 + 13) into the file, followed by the absolute values as above. I also changed the character count parameter, to allow for the space or "-" in the string, but I'm not sure I did that right. I also took out the //10 out of the DEC1 modifiers.
You could also handle the the data in Kelvin (always positive!) instead of Celsius or, if you can be satisfied with resolution to 1 degree Celsius instead of 0.1 degree, the SDEC modifier can be used instead of DEC. SDEC takes care of the "-" for you, but it works with integers only.
The Stamps-in-class lessons here are 1) there are many ways to implement any programming problem and 2) think ahead to cover the full range of values you will encounter.
There is another issue. The humidity calculation for temperature compensation will be wildly incorrect at negative temperatures. That is due to the calculation of.
(tC/10 - 25)
Will be wrong when tC is negative.
One correct way to do that would be
(ABS tC / 10 ^ -tC.bit15 + tC.bit15 - 25)
That calculation may look a little strange, but the way it works is to take the the ABSolute value of tC, then divide that by 10, and then do a conditional twos complement negation. That restores the sign of the original tC. Then subtract 25.
The calculation of humidity is quite different from the way I do it in my programs, so I think I'll take a closer look at it. It is another one of those cases where there are different ways to go with it.
Tracy,
I haven't had a chance to test our board in minus Celsius conditions, but, I have made the changes in the program. Thank you so much for your help,
Andrew
Thanks for the updates! The students are running wild with their new-found passion: programming (or, a rudimentary attempt at learning it anyway!) The program seems to be running smoothly now, displaying and writing data to the flash drive in degrees Celsius and percent humidity, both to the tenth of a unit.
Doubtful (or rather, hopeful!) that our rocket would get high enough to register in negative Celsius degrees (the stratosphere?) But I'm curious about the adding the program line to display temperatures below 0 degrees anyway. Where does the code you posted (below, and above) go in the program? Which command line(s) does it replace? Thanks again! You're teaching a lot of great information to many new-found friends.
One correct way to do that would be: (ABS tC / 10 ^ -tC.bit15 + tC.bit15 - 25)
Comments
SEROUT TX\CTS, Baud, [noparse][[/noparse]DEC tC, ",", DEC rHLin, CR, LF]to this one
SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 tC, ",", DEC5 rHLin, CR, LF, CR]The problem was that the datalogger requires some additional control codes and length information for the text to be written. Unsoundcode had already mentioned it.
·· Success! The data now writes to the USB flash drive! It appears like this:
1, 263, 223
2, 262, 223
3, 262, 222
4, 261, 221
5, 260, 220, etc, etc for·whatever·NumSamples
When I breathe gently across the sensor the second number changes relatively fast. I suspect the second number is humidity.
How do we go about changing the "200's data" (above)·to readable degrees and percent humidity? I see in the sample program for the SHT11 humidity/temperature sensor that there are some conversions in the program code. They appear to be the same, or very similar,·to those in your program, but in a different sequence(?)
I tried adding Unsoundcode's 'fix' yesterday but was uncertain exactly where it went (sorry, Unsoundcode. Stick with us!)·You got the Datalogger to actually log data! We're almost there. Now, how·do we·get the data to output in readable, recognizable units (degrees and percent humidity??)
Thanks again, Mike, and everyone.·You're geniuses!
Good evening from NH,
Mark Kibler
Weare Schools rocketry team
With the two numbers on one line separated by a comma, you should be able to read this file into Excel for analysis including graphing. It's what is known as Comma Separated Values (CSV).
Post Edited (Mike Green) : 1/31/2008 4:50:17 AM GMT
We replaced these lines as suggested:
DEBUG DEC counter,", ",DEC tC,", ",DEC rHLin,CR,LF
SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 tC, ",", DEC5 rHLin, CR, LF, CR]
With the code you posted, in this order:
DEBUG "#",counter," ",DEC3 tC/10,".",DEC1 tC//10,", ",DEC3 rHLin/10,".",DEC1 rHLin//10,CR,LF
SEROUT TX\CTS, Baud, [noparse][[/noparse]$8,$20,0,0,0,13,CR,DEC3 (tC/10),".", DEC1 tC//10,",",DEC3 (rhLin/10),".",DEC1 rhLin//10,CR,LF,CR]
But we get an ‘EEPROM FULL’ error…
Question 1: Does ‘EEPROM FULL” mean that one of the two lines of new code is “full”? (If not, what does it mean?)
Question 2: Did I replace the correct lines of code?
Question 3: How do we resolve it?
Thanks, as always!
Mark and the crew
Jeff T.
·· I'm not sure what "commenting out the Debug instruction means." I believe it means to delete any extra text associated with the program command line. But I'm not sure what to delete, or where. Thanks for your post! Standing by...
Mark
Any line which begins with a single apostrophe is taken to be a comment. So too anything after a single apostrophe on a line which contains operational instructions (commands). Here is an example of the former using a DEBUG command as the example:
Present Line for Debugging -
DEBUG "Program is starting"
Change that line to a comment -
'DEBUG "Program is starting"
The first is executed as a command, and the second is ignored as a comment.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!
It can also be used at the start of a line of code you dont want to download but dont want to delete right away, the apostrophe virtually removes the code from the program with one keystroke and replaces, if wanted, with another keystroke.
Trying to see just how full the EEPROM was I suggested "commenting" out this line
·· ' DEBUG "#",counter," ",DEC3 tC/10,".",DEC1 tC//10,", ",DEC3 rHLin/10,".",DEC1 rHLin//10,CR,LF
Jeff T.
Yes, thanks. I saw that when I placed an apostrophe ' in front of a line command it was changed to a comment. I also deleted some of the extra words insode previous DEBUG command quotes (e.g. DEBUG "The program is in the process of starting" was simplified to "Start program". This freed up EEPROM space and the program now runs.
The command lines:
DEBUG "#",counter," ",DEC3 tC/10,".",DEC1 tC//10,", ",DEC3 rHLin/10,".",DEC1 rHLin//10,CR,LF
SEROUT TX\CTS, Baud, [noparse][[/noparse]$8,$20,0,0,0,13,CR,DEC3 (tC/10),".", DEC1 tC//10,",",DEC3 (rhLin/10),".",DEC1 rhLin//10,CR,LF,CR]
scatter the data all the screen, though, and even on top of the text when the program runs. How do we get the data the 'print out' in neat rows as before, without any extra 0's in front of the data (25.6 degrees instead of 00256)?
Thanks so much for your valuable time, your replies, and for sharing your wealth of expertise with us. Slowly, we're learning the 'basics' (pun intended!)
Mark
The DEBUG line should be
Without the DEC, the value of counter is sent as a byte to the PC where it does odd things to the debug window display.
The above changes remove the leading zeroes from the numbers. Also, by putting DEC in front of counter, it avoids the messages
from getting scattered all over the debug window. In the case of the memory stick file data, you can't do the same thing since there
always has to be the same number of characters per line. It would be possible to substitute spaces for the leading zeroes, but that
complicates an already large program and, if you use something like Excel to read in the data for analysis, the leading zeroes won't
matter.
By eliminating the leading zeros in the debug display, the data may not line up any more. Again, that's fixable, but would make the
program bigger.
At a mile high no one will see the leading zeros anyway
Removal of all the debug instructions will hopefully provide the room you will need for the code that sets the logger in motion.
Jeff T.
I'm on Mr. Kibler's (Mark in NH) rocketry team. I have been following along with all of you in the forum. I've made all of the same changes to the "RocketRobotProgram" that you have all been making. When I downloaded the program to my board and open up a debug window, it gets up to the point of "Acessing..." and it just hangs there. Is there something I did wrong or need to do? If someone could post the most recent version of "RocketRobotProgram", that would be great. Thanks in advance,
Andrew
Mr. Kibler should have the most recent version. I posted a version on 1/29 and there have been some corrections since then described in this thread that you would have to apply.
The "Accessing..." message is shown while the Datalogger is waiting for a formatted memory stick to be detected. Specifically, it's waiting for the Vinculum chip to send a "DD" status value. There's a complete description of the Vinculum commands and status responses for the Datalogger in the firmware manual. Download the VDAP Firmware Spec manual via the link given here: www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/txtSearch/datalogger/List/1/ProductID/434/Default.aspx?SortField=ProductName%2cProductName
Thank you for your quick response. I've just downloaded and read the VDAP Firmware Manual. Like Mr. Kibler, I do not have a lot of programming experience in this language. What exactly should I do once I get the most recent version of "RocketRobotProgram". Should I re-format my drive, maybe? Thanks,
Andrew
The first question is "what has worked so far?". Are you working with the same hardware as Mr. Kibler? If not, you should start there and make sure your hardware setup is identical to the one that Mr. Kibler was using. It sounded like the program had worked with the Datalogger, recording data on a file. Is that not so? If it has never fully worked, what really did happen earlier? Before you do anything further, you really need to find out what has happened before and communicate that here.
One of the most basic ideas of programming and debugging is thinking (in an orderly fashion), understanding (what you're trying to do, what has been done before, and what is actually being attempted now), and communicating (to others).
I am using the same exact hardware and setup as Mr. Kibler. I am also able to use the sample program with the data logger to record random numbers, but not using the same USB drive as I am currently trying to use.
Andrew
·· Mr. Kibler here. Just so everyone is on the same page, we are all using the same set up: Parallax 'Board of Education', Sensirion hundity/temperature sensor, and a Parallax Flash Stick Datalogger.
Andrew, I'll e-mail you the most recently updated program that everyone on the forum has helped write. Be sure to thank them profusely because they've been very patience, and very generous with their time and expertise.·The program·works really well now, with just a few minor 'bugs' to work out. You, Tim, and Tyler·should be working independently, then as a project team during practice to do this.
Once I e-mail you the newest working program, paste and save·it into a Parallax BS2 file, then start 'debugging'. I would suggest that you start with this recent post in the forum, but certainly read and·use them all. Again, be sure to thank everyone on the forum as they guide as through the fun and challenging lesson of learning progarm language. Thanks, guys!
from last night or early today:
"Mark,
"The DEBUG line should be
Without the DEC, the value of counter is sent as a byte to the PC where it does odd things to the debug window display.
·
When I tried formatting the flash drive as a FAT with an allocation table of 16, I got an error message that stated, "The cluster size is too big for the current drive. When I tried formatting it as a FAT with an allocation table of 32, I got the same error. My drive is an Imation 64MB and I tried to format it using my laptop running Windows Vista. Is there a problem with the drive, or my computer? Or is it just how I am trying to format it (using the disk management program included with vista).
Thanks in advance,
Andrew
You probably will do better with a larger flash drive. I've seen 1GB drives for as little as $10 in the last few months. I use Windows XP which seems to use a default cluster size of 16KB with a 1GB drive.
I do agree my drive is quite small. It is so amazing how the price of flash drives have been dropping over the years. I guess I'll end up getting a new one. Do you have any suggestions for flash drives that you think would be suitable for my project.
Thanks,
Andrew
I suggest you try formatting your drive with a smaller cluster size first. If that works, try it with the Datalogger.
If you can't get the 64MB drive to work, see if you can get a "generic" 1GB flash drive. Radio Shack has 512MB
and 1GB USB flash drives for $5 to $15. You shouldn't have to pay more than $20. Best Buy should have similar
prices.
I'll try your advice. If I can't get my 64MB drive working, I'll probably end up buying a new one. I'll let you know how things work out. Thanks again,
Andrew
You could also see if your local Radio Shack or Best Buy would contribute a 1GB flash drive to your project, then have your teacher and the students on the project send a thank you note both to the local store and the national corporate office.
I started formatting the memory sticks Fat 32 with an allocation unit size of 512 bytes and so far have had no problems in that format with the logger. I don't know why I just know it works for me. I wondered if anyone had any comments that might help me understand why 512 is a "magic" number. This is not just a problem with small drives, it works with a Lexar 64M, PNY 1G, Sandisk 1G, and a PQI 1G.
Jeff T.
That is only important if you need to conserve eeprom space to fit more program.
On this flight, you are quite likely to encounter negative Celsius temperatures, and the above debug code will not display them correctly. Here is wide-range display code.
To explain, the REP modifier causes a REPetition of the "-" sign either zero or one time, depending on bit 15 of the tC variable. That is the sign bit. It is 1 for negative, 0 for positive or zero. Then comes the DECimal value of the ABSolute value of tC. In the Stamp, division like tC/10 or tC//10 do not work correctly on negative numbers (in the Stamp, negative numbers are in a form called "twos complement", but the Stamp has very limited capability to do math with the negatives).
You would also need to do a similar thing in the output to the flash drive, except with consideration for the fixed field lengths.
This takes care of the sign in a different way, to allow for the fixed field requirement. Here it puts either a space (asciii value =32) or a minus sign (ascii value = 45 = 32 + 13) into the file, followed by the absolute values as above. I also changed the character count parameter, to allow for the space or "-" in the string, but I'm not sure I did that right. I also took out the //10 out of the DEC1 modifiers.
You could also handle the the data in Kelvin (always positive!) instead of Celsius or, if you can be satisfied with resolution to 1 degree Celsius instead of 0.1 degree, the SDEC modifier can be used instead of DEC. SDEC takes care of the "-" for you, but it works with integers only.
The Stamps-in-class lessons here are 1) there are many ways to implement any programming problem and 2) think ahead to cover the full range of values you will encounter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/1/2008 7:39:16 PM GMT
Andrew
(tC/10 - 25)
Will be wrong when tC is negative.
One correct way to do that would be
(ABS tC / 10 ^ -tC.bit15 + tC.bit15 - 25)
That calculation may look a little strange, but the way it works is to take the the ABSolute value of tC, then divide that by 10, and then do a conditional twos complement negation. That restores the sign of the original tC. Then subtract 25.
The calculation of humidity is quite different from the way I do it in my programs, so I think I'll take a closer look at it. It is another one of those cases where there are different ways to go with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I haven't had a chance to test our board in minus Celsius conditions, but, I have made the changes in the program. Thank you so much for your help,
Andrew
Thanks for the updates! The students are running wild with their new-found passion: programming (or, a rudimentary attempt at learning it anyway!) The program seems to be running smoothly now, displaying and writing data to the flash drive in degrees Celsius and percent humidity, both to the tenth of a unit.
Doubtful (or rather, hopeful!) that our rocket would get high enough to register in negative Celsius degrees (the stratosphere?) But I'm curious about the adding the program line to display temperatures below 0 degrees anyway. Where does the code you posted (below, and above) go in the program? Which command line(s) does it replace? Thanks again! You're teaching a lot of great information to many new-found friends.
One correct way to do that would be: (ABS tC / 10 ^ -tC.bit15 + tC.bit15 - 25)
Regards,
Mark