Back to the drawing board! New problem, when I plug the USB cable back into the Badge, that procedure makes the Badge reboot. So, that means when you want to plug in for a recharge, everything gets set back to a fresh start, and then you have to redo everything.
This is starting to look like a problem that cannot be overcome, for what I want to do. If it keeps rebooting every time you want a charge, and you do not have an RTC to reset the clock program and you have to do everything over again, this is starting to put some real drastic limits on the usefulness of a Hackable Badge, but I could be wrong about this, I hope somebody from Parallax will confirm or deny this.
I guess that is why a lot of the examples rely on the EEPROM, like passing data back and forth, the Badge can be rebooted all the time without losing the data on the EEPROM. Not sure if you could run a reliable clock by putting the last time on the EEPROM, and then having that loaded in, maybe a slow clock is acceptable. But maybe there some traces that can be cut... :-)
A computer will reset the badge when you connect it.
Since the badge is hackable, it means you can put a hardware RTC on it. That would probably be the most effective solution for the app you are working on.
Another approach would be to assume that it will receive a time update when plugged into a PC.
A third approach would be to press a button to tell the badge to start tracking time with EEPROM because you are about to plug it into a computer's USB port.
Any power source to the USB will reset the Badge. I just tested with my cell phone power cable, it is just plain power, not connected to a computer, that caused the Badge to be rebooted. It looks like anything with power, that is plugged into the Badge USB, will cause it to reboot.
I guess one other thing that I could try is the IR thing, after a charge and a reset, pass it by another IR source that would update the Badge with the real time. I wonder if their would any problems with that? Maybe a problem that could come up is with the transfer of the data itself. Can the IR transfer all of the date time fields, without distortion, and be in a usable form on the Badge to reset the clock correctly? Another item that has to be tested, before a commit.
Hi Ray, a few random ideas here to experiment with...
Your terminal software may allow you to invert state of dtr before connecting.
Ft-prog software, downloadable from ftdi website, allows you to invert state of the dtr output.
If you disable usb control of dtr, you could manually reset the badge when you want to by touching the reset egg with a screwdriver tip (or somesuch metal object)
[edit] Receive used dts in original post, but changed to dtt (temporary) then copied to dts (system).[/edit]
Alternately, you could just use a single int: dts.etv. That's the number of seconds since Midnight 1/1/70. After receiving, setting the time would probably be easier with something like this added to the datetime library.
Just an observation:
Last night I decided to "top off" the Badge battery, after the blue LED went off, the battery voltage was 4.17V. I unplugged the USB cable, and let it sit until this morning, when I measured again, and the reading was 4.11V.
The first thing that came to mind was, why the measurement was not 4.17V? I was thinking, is there something on the Badge that is drawing power, when it is unplugged and turned off? Hmm, do I have to run a twenty four hour test, to see what kind of voltage loss occurs. Then the next question would be, why? Maybe some body has a good explanation for this?
Within 30 mins or so of charging, most batts will settle a bit due to chemistry changes / temp changes.
The badge will have almost zero current draw when off...
As you have been doing, and ponder more, I would encourage you to keep testing and experimenting... Very interesting to follow your progress, and for sure the best way to learn and observe how the features work in your own circuit.
On a personal note, I am not so much testing the Badge, as I am testing my seventy year old brain body combo. I am glad to see that I still have a bit of a sensible curiosity about different things, but maybe that is just regression that is setting in, that topic is not for discussion on this forum.:-)
Below is my first attempt at passing something, using the IR. Not quite there yet. Basically the Badge is getting something, but not what I am expecting. I am trying to pass data from the QS+HIB to the Badge.
In the QS+HIB setup, I am using badgetools.h, changes made, I also made the changes in the badge_setup() function, and changed the IR_IN = 8 IR_OUT = 9, to match, but I must of missed something. Also when I do use the sendclock() function, it hangs the program, so there must be something I am missing with the send_ir that is not working with the QS+HIB, I think.
On the Badge it is just a straight forward press the P27 button to receive, while the clock COG is running. I left my attempt at passing actual datetime data, that was not working very well.
Ray
Badge
/*
stIRclock.c
October 4, 2015
Staff Badge
*/
#include "simpletools.h" // Include simple tools
#include "badgetools.h"
#include "datetime.h"
datetime dts = {2000, 1, 1, 0, 0, 0}; // seed value.
datetime dta, dtt;
int states;
/* COG functions */
void System_base();
void Getsetclock();
int main() // Main function
{
// Add startup code here.
badge_setup(); // Setup the badge.
dt_start(&dts); // Start the date time.
/* Start the system base utilities. */
cog_run(System_base,128);
while(1)
{
// Add main loop code here.
while(!buttons())
{
while((states = buttons()) == 0); // Wait for button press.
switch(states)
{
case 0b0000001: // Button P27
//Get_date();
pause(100);
Getsetclock(); // Run the battery gauge.
continue;
default:
continue;
}
if(states == 0b0000100) continue; // Button release?
}
}
}
/* COG for running base utilty. */
System_base()
{
while(1)
{
cursor(0,7);
text_size(SMALL);
oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s);
cursor(8,7);
/* month day year, last two digits */
oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100);
}
}
void Getsetclock()
{
char inDat[10];
/* rgb(R,GREEN);
irscan("%d%d%d%d%d%d",
&dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s);
dt_copy(&dts, &dtt);
rgb(R,RED);
pause(3000);
rgb(R,OFF); */
irscan("%s",inDat);
cursor(0,6);
text_size(SMALL);
// oledprint("%02d:%02d:%02d%02d/%02d/%02d"
// ,dts.h, dts.m, dts.s,dts.mo, dts.d, dts.y % 100);
oledprint("%s",inDat);
}
It might need some tuning, but here is a first cut at a battery voltage measurement function. It uses the info you reported earlier 4.17V with t = 01435. Temperature could be a factor, and there may be other realities that have to be compensated. So, let's go ahead and try this and find out what they might be...
With your situation above, we don't know whether there's a bug in the app code, or in the library modifications.
How about if we start with something known to work on a pair of badges first. The examples below work on my pair of badges; please make sure they work for you too. If yes, then try the library mods again and switch to your QS + HIB. I'm assuming that means a QuickStart and Human Interface Board.
To reduce debugging, I started with "03 Send Data with IR.side", and "04 Receive and Store IR Data.side" from an unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder. Then added in parts from "Test datetime Library.side" and the irprint/scan stuff from a few posts earlier.
/*
Receive Time with IR.c
*/
#include "simpletools.h" // Include simpletools library
#include "badgetools.h" // Include badgetools library
#include "datetime.h"
datetime dtt;
int states;
void main() // Main function
{
badge_setup(); // Call badge setup
while(1)
{
clear(); // Menu
text_size(LARGE);
oledprint(" IR Rcv ");
text_size(SMALL);
cursor(0, 5);
oledprint(" Receive-P27\n");
text_size(LARGE);
while(1) // Wait for button press
{
states = buttons();
if(states) break;
}
if(states != 0b0000001) // Not P27?, try again
{
cursor(0, 0);
text_size(LARGE);
oledprint(" Try Again ");
pause(1000);
continue; // Back to while(1)
}
// P27 has to have been pressed to get to here
clear();
oledprint("Ready for IR "); // Display ready for IR
// Wait for IR message
irclear(); // Clear ir com buffers
memset(&dtt, 0, sizeof(datetime)); // Clear their variables
while(1)
{
irscan("%d%d%d%d%d%d",
&dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s);
if(dtt.y > 0)
{
break;
}
}
clear(); // Menu, what to do with data
text_size(SMALL);
cursor(0, 5);
oledprint("%04d/%02d/%02d\n%02d:%02d:%02d:",
dtt.y, dtt.mo, dtt.d, dtt.h, dtt.m, dtt.s);
cursor(0, 7);
oledprint(" OK-P25");
while((states = buttons()) == 0); // Wait for button press
text_size(LARGE); // Act on button press
pause(500);
}
}
Thanks Andy, I will get to your new program examples later on today, my Guest Badge is busy at the moment.
Yesterday I decided to take my Guest Badge out of its package, yes, the Badge had the brown sticky paper on the plastic OLED shield. It also had some writing on the paper, nothing like "peel me off", but it did make it obvious that it should be removed somehow. Again, a sharp knife to loosen up the paper somewhere in the corner edge of the plastic shield. The difference between the Staff and the Guest Badge, the Staff Badge did not have any writing on the brown paper. I assume mine was the one that got away with no writing on the brown sticky paper.
The Guest Badge is now doing a twenty four hour test, I have just the clock program running in its own COG. When the test time is up I will then check to see how well it is keeping time, with the new datetime program, and I will check the battery usage. So far the new datetime program is working just as well as the datetime lib that comes with the C libs.
An observation:
As I expand my usage of the Badge(s) and peripheral items(QS+HIB), it sure would be nice if the simpletools lib had some itemized sub libs. Yesterday I noticed that in order to use the QS+HIB, I did not find any tools, in an easy to implement fashion, to utilize the IR and later on, the access to the EEPROM for a comm session with a Badge(s). I guess the further you move along with the badgetools lib, the harder it will be, or least time consuming, when or if it is decided to itemize some of the functions into some manageable libs for use with other devices.
When you are using SimpleIDE, and you have your Badge plugged in, but not turned on, the COMx should have a number that is associated with your device. When I first plugged in the Badge, my Windows 7 program did go through an "installing driver" session. Since I am using my Windows 7 box, I am not sure if a Windows 10 setup would have any problem finding and installing a suitable driver.
Next up, I will give that battery voltage program that Andy developed, a try. I would like to have a piece of firmware, that maybe starts up on your Badge that displays a clock and maybe a button press that shows you the battery status.
Ray
footnote: QS = QuickStart, HIB = Human Interface Board, for the QuickStart.
Test Results:
The new Battery Voltage program, that Andy developed, worked as expected. A voltmeter reading was confirming the voltage that was displayed on the screen. Since the program is using the 4.17 and 1435 values, I guess that the values are valid?
My twenty four hour attempted run, came up short, the Badge was no longer showing the clock after ~21 hours.
Start:
Running the clock in its own COG which displays a constant time update on the OLED screen.
Battery voltage - 4.14V(settled volts)
Stop:
~21 hour duration.
Battery voltage - 3.4V
Recharge time - 3.4V to 4.17V, approximately 2 hours.
I guess, now I have a bottom limit for the battery voltage, for non intensive demand programs, I have a sense for when its absolutely necessary to plug in. As you start loading up the program with things like using the LEDs and other things, it becomes crucial to know the battery state. I guess the battery voltage program can be put in the clock COG, and maybe have a button that displays what the current voltage is. It also becomes a necessity to have some kind of auto clock update via the IR, I think a good temporary candidate could be the QS+HIB. Hmm a lot to think about.
I'm deep into another task just now, but just to add some support to your findings.... those runtime figures seem about right with what I found during trials. The battery itself also has a safety cutout level (little pcb inside the battery), to prevent the battery discharging too low and being damaged. I really cannot recall the specs at the moment, but I thought that was around 3.2V. Maybe 3.4V.
Do you have the grey "Parallax" branded battery, or another type?
Anyway... I must get back to task, but if you wish to attach a zip file with the code here, I'd be happy to run the same test and compare battery results later in the week. I just received some of the new Parallax batteries on Friday, so they need a good test anyway!
Just thought of something, if the battery voltage was 3.40V, when the OLED screen went blank, then why did it go blank? I thought that the Propeller needed just 3.3V to stay active? So, something is not right with my reading of the discharged battery. Anyway, the safety reading for the my badge will be 3.5V, as an absolute "get it plugged in".
The battery is what came with the Badge(s), not ready to start testing other batteries.
Here is a video of a large piece of Plexiglass. You will notice there is printing on one side, but blank on the other. I depends on which side Parallax cuts it, up or down. Then they peal the down side of the plexi and leaves the top side covered.
Just thought of something, if the battery voltage was 3.40V, when the OLED screen went blank, then why did it go blank? I thought that the Propeller needed just 3.3V to stay active? So, something is not right with my reading of the discharged battery. Anyway, the safety reading for the my badge will be 3.5V, as an absolute "get it plugged in".
The battery is what came with the Badge(s), not ready to start testing other batteries.
Ray
The OLED is powered by both 3.3V and VBATT.
3.3V from the same regulator powering the Propeller,
AND also directly to the battery voltage to power the display (as that needs higher voltage).
I'm not in a place I can check, but from memory the OLED specifies typical VBATT min is 3.5V. I'd say your findings are correct.
About the batts... sorry, what I meant was that Parallax were shipping some green or blue colored batteries prior to getting stocks of the grey Parallax branded batteries. If you had an early release badge, you might not have got the Parallax branded battery- and that may have had different specs. So I just wanted to make sure we were comparing the same battery- AND it seems we are! Phew!
I just did some more testing of the Battery Voltage program (Andy), running into a problem. The numbers, 4.17 and 1435 values, seem to work for my Staff Badge, but when I run the program on the Guest Badge, it is showing the wrong voltage.
The 4.17 and 1435 values, I got from testing the Staff Badge. I wonder, if each Badge, with the battery inserted has their own specific RTC value at the voltage measured by a voltmeter. I guess Parallax will have to verify this, they have multiple Badges and batteries to work with.
You will have some tolerance between badges due to tolerance in the sampling components, and also slightly according to ambient temperature if the badges are tested in different conditions.
Essentially the rctime circuit involves 2 resistors and a capacitor. I'm sure we used 1% tolerance parts. You would ideally want to do a 1time calibration of each badge.
Interesting test results this morning. Pursuing this battery voltage (Andy) thing today, I decided to check the RTC value for the Guest Badge.
The value that came up was, @ 4.17V RTC was 1471. This number is quite a bit different than what the Staff Badge had, which was, @ 4.17V RTC was 1435.
Not sure how to interpret the data, is it the battery characteristics, or is it the Badge battery circuit characteristics, or both? Since I only have two badges and two batteries, I am not sure if this is just a fluke or is this something that needs a work around.
If it is the battery characteristics, RTC value changing for a specified voltage reading, with usage of the battery perhaps, then I guess a calibration or maybe some kind of maintenance firmware program would become a useful item to develop. This would probably become necessary due to the fact that the battery would have to changed out at some point, and of course the new battery would have its own RTC value, I think. So, are there batteries that have a common consistent RTC rating? Or, is it the Badge battery circuit, or both? Or, maybe it is neither, and I am just having a senior incident. :-)
In simplest terms, the voltage being tested will be constant (ie. any battery you might connect), but the sensing circuits WILL vary in how they interpret the voltage because each badge is subject to the tolerance of it's own sensing circuit.
However, for the sake of keeping this simple, we can say that the tolerance factor won't change once a badge is built. The tolerance is a factor of the components on the badge, and what I mean is that once those 1% or 5% parts are soldered into the badge, they are not going to change (unless the user changes them
So calibrating each badge ONCE at the start of it's life should be sufficient to measure any voltage (or therefore battery) connected now or later.
You probably (or Andy probably) used the value of the sense resistor and capacitor in the calculation (formula). The sense resistor may nominally be included as value 360K, but the tolerance is 1%. Therefore the actual value will vary on each badge in the approximate range: 356K to 364K. If you plug these min and max values into the same formula, you will probably find the resulting range of possible RTC values covers the readings you have experienced.
To calibrate, you might be comfortable just reading the sense resistor with a multimeter and adding that value to your code, or you might take some sample readings and caclulate an offset that way. The resistor in question will be the one giving you a value close to 360K over on the right of the Propeller chip, near to the RCT egg.
Thanks VonSzarvas, maybe an official Parallax Tech Note for this should be made available, along with a Spin object and C function example, developed by a Tech, for showing the voltage. I would hate to think that I am the only one that would be concerned with a battery voltage status.
The other thing that I noticed today, is the OLED displaying a previous oledprint() on the screen, even after the Badge is powered off. Does the OLED screen have some kind of memory associated with it?
Ray
Footnote: Tech = maybe an electrical engineer, or a plain old tech person. Or maybe a plain young tech person.:-)
The other thing that I noticed today, is the OLED displaying a previous oledprint() on the screen, even after the Badge is powered off. Does the OLED screen have some kind of memory associated with it?
Ray
That was mentioned in another thread. I only happens when the USB cable is plugged in, right? If so, that's normal.
(As I recall the 3.3V rail will be about 2V when USB is connected and the badge is off - FTDI sourced "parasitic" power - so if you use an LED with close to 3.3V Vf and a decent size series R then that same LED will indicate power state for both USB and Battery power. We may change that in future versions, and add some other battery polarity and safety circuitry too, but for this first version we've gone with simple-as-possible and no-protection approach, to allow users maximum unhindered hacking possibilities!).
Ahh, this explains the ghostly OLED image I see while USB is connected.
Just an observation:
Last night I decided to "top off" the Badge battery, after the blue LED went off, the battery voltage was 4.17V. I unplugged the USB cable, and let it sit until this morning, when I measured again, and the reading was 4.11V.
The first thing that came to mind was, why the measurement was not 4.17V? I was thinking, is there something on the Badge that is drawing power, when it is unplugged and turned off? Hmm, do I have to run a twenty four hour test, to see what kind of voltage loss occurs. Then the next question would be, why? Maybe some body has a good explanation for this?
Ray
Ray, if you look at the schematic, U203 and possibly Q201 are always under battery power. U203 is for the electronic switch. Since it's not a physical switch, it needs power to sense the button push.
Below is my rendition for receiving an IR stream that sets the clock that is running in its own COG. This seems to be working as expected, but I sure am having rough time with the button controls.
I set up my Staff Badge to be the sender, and my Guest Badge to be the receiver. Is there a listing of the binary numbers that are assigned to the buttons, all seven? Boy do I miss having a text_size(MEDIUM), maybe takes up two lines for the text size.
Ray
/*
gIRtest.c
October 6, 2015
* Guest Badge IR receive.
*/
#include "simpletools.h"
#include "badgetools.h"
#include "datetime.h"
datetime dts = {2000, 1, 1, 0, 0, 0};
datetime dta, dtt;
int states;
void System_base();
void bLine();
int main()
{
// Add startup code here.
badge_setup();
dt_start(&dts);
text_size(SMALL);
oledprint("Any BTN for Menu");
pause(300);
cog_run(System_base,128);
while(1)
{
// Add main loop code here.
text_size(SMALL);
while(!buttons());
cursor(0,0);
bLine();
cursor(0,0);
oledprint("Receive-P27 ");
while((states = buttons()) == 0);
switch(states)
{
case 0b0000001: //button P27
cursor(0,0);
bLine();
cursor(0, 3);
text_size(SMALL);
oledprint("Waiting for IR");
cursor(0,3);
oledprint("Ready for IR "); // Display ready for IR
// Wait for IR message
irclear(); // Clear ir com buffers
memset(&dtt, 0, sizeof(datetime)); // Clear their variables
while(1)
{
irscan("%d%d%d%d%d%d",
&dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s);
if(dtt.y > 0)
{
dt_copy(&dts, &dtt);
cursor(0,0);
bLine();
cursor(0,3);
bLine();
cursor(0,6);
oledprint("Got it ");
break;
}
}
continue;
}
}
}
void bLine()
{
oledprint(" ");
}
/* COG for running base utilty. */
void System_base()
{
while(1)
{
cursor(0,7);
text_size(SMALL);
oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s);
cursor(8,7);
/* month day year, last two digits */
oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100);
}
}
Referring back to the unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder, there's info in "Documentation badgetools Library.html" file; follow the button and buttons links in the Functions list. Also check the example programs in the "3 Buttons" folder.
In summary of those two resources:
When you call int state = button(number), number can be:
...
cursor(0, 0);
int state = button(4);
if(state == 1)
{
oledprint("P16 ON ");
led(4, ON);
}
else
{
oledprint("P16 OFF");
led(4, OFF);
}
...
When you call int states = buttons();
The states result will contain 7 bits, 0b0000000. The bits correspond to {OSH, P17, P16, P15, P25, P26, P27}. Example:
...
int states = buttons();
if(states == 0b0000100)
{
oledprint("P25 ON ");
leds(0b000100);
}
else
{
oledprint("P25 OFF");
leds(0b000000);
}
...
Note: If you expect to be responding to several different button press or combination possibilities, it's best to use the buttons function and capture them all at once. Then, go through with a series of if... statements or a switch... statement to decide what to do about the input.
Comments
This is starting to look like a problem that cannot be overcome, for what I want to do. If it keeps rebooting every time you want a charge, and you do not have an RTC to reset the clock program and you have to do everything over again, this is starting to put some real drastic limits on the usefulness of a Hackable Badge, but I could be wrong about this, I hope somebody from Parallax will confirm or deny this.
I guess that is why a lot of the examples rely on the EEPROM, like passing data back and forth, the Badge can be rebooted all the time without losing the data on the EEPROM. Not sure if you could run a reliable clock by putting the last time on the EEPROM, and then having that loaded in, maybe a slow clock is acceptable. But maybe there some traces that can be cut... :-)
Ray
Since the badge is hackable, it means you can put a hardware RTC on it. That would probably be the most effective solution for the app you are working on.
Another approach would be to assume that it will receive a time update when plugged into a PC.
A third approach would be to press a button to tell the badge to start tracking time with EEPROM because you are about to plug it into a computer's USB port.
I guess one other thing that I could try is the IR thing, after a charge and a reset, pass it by another IR source that would update the Badge with the real time. I wonder if their would any problems with that? Maybe a problem that could come up is with the transfer of the data itself. Can the IR transfer all of the date time fields, without distortion, and be in a usable form on the Badge to reset the clock correctly? Another item that has to be tested, before a commit.
Ray
Your terminal software may allow you to invert state of dtr before connecting.
Ft-prog software, downloadable from ftdi website, allows you to invert state of the dtr output.
If you disable usb control of dtr, you could manually reset the badge when you want to by touching the reset egg with a screwdriver tip (or somesuch metal object)
irprint("%04d\n%02d\n%02d\n%02d\n%02d\n%02d\n", dts.y, dts.mo, dts.d, dts.h, dts.m, dts.s);Receiving would be something along the lines of:
irscan("%d%d%d%d%d%d", &dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s); dt_copy(&dts, &dtt);[edit] Receive used dts in original post, but changed to dtt (temporary) then copied to dts (system).[/edit]
Alternately, you could just use a single int: dts.etv. That's the number of seconds since Midnight 1/1/70. After receiving, setting the time would probably be easier with something like this added to the datetime library.
#include "simpletools.h" #include "datetime.h" volatile int dtlock; void dt_setEt(datetime *dt, int etv) { while(lockset(dtlock)); dt->etv = etv; int dNow = dte_dateETV(dt->etv); int tNow = dte_timeETV(dt->etv); dt->y = dNow >> 16; dt->mo = (dNow >> 8) & 0xFF; dt->d = dNow & 0xFF; dt->h = tNow >> 16; dt->m = (tNow >> 8) & 0xFF; dt->s = tNow & 0xFF; lockclr(dtlock); }Last night I decided to "top off" the Badge battery, after the blue LED went off, the battery voltage was 4.17V. I unplugged the USB cable, and let it sit until this morning, when I measured again, and the reading was 4.11V.
The first thing that came to mind was, why the measurement was not 4.17V? I was thinking, is there something on the Badge that is drawing power, when it is unplugged and turned off? Hmm, do I have to run a twenty four hour test, to see what kind of voltage loss occurs. Then the next question would be, why? Maybe some body has a good explanation for this?
Ray
The badge will have almost zero current draw when off...
As you have been doing, and ponder more, I would encourage you to keep testing and experimenting... Very interesting to follow your progress, and for sure the best way to learn and observe how the features work in your own circuit.
Ray
The brain may only slow as you do, so Keep being curious I say! An active whatever leads a fun life forever.
In the QS+HIB setup, I am using badgetools.h, changes made, I also made the changes in the badge_setup() function, and changed the IR_IN = 8 IR_OUT = 9, to match, but I must of missed something. Also when I do use the sendclock() function, it hangs the program, so there must be something I am missing with the send_ir that is not working with the QS+HIB, I think.
On the Badge it is just a straight forward press the P27 button to receive, while the clock COG is running. I left my attempt at passing actual datetime data, that was not working very well.
Ray
Badge
/* stIRclock.c October 4, 2015 Staff Badge */ #include "simpletools.h" // Include simple tools #include "badgetools.h" #include "datetime.h" datetime dts = {2000, 1, 1, 0, 0, 0}; // seed value. datetime dta, dtt; int states; /* COG functions */ void System_base(); void Getsetclock(); int main() // Main function { // Add startup code here. badge_setup(); // Setup the badge. dt_start(&dts); // Start the date time. /* Start the system base utilities. */ cog_run(System_base,128); while(1) { // Add main loop code here. while(!buttons()) { while((states = buttons()) == 0); // Wait for button press. switch(states) { case 0b0000001: // Button P27 //Get_date(); pause(100); Getsetclock(); // Run the battery gauge. continue; default: continue; } if(states == 0b0000100) continue; // Button release? } } } /* COG for running base utilty. */ System_base() { while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,7); /* month day year, last two digits */ oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100); } } void Getsetclock() { char inDat[10]; /* rgb(R,GREEN); irscan("%d%d%d%d%d%d", &dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s); dt_copy(&dts, &dtt); rgb(R,RED); pause(3000); rgb(R,OFF); */ irscan("%s",inDat); cursor(0,6); text_size(SMALL); // oledprint("%02d:%02d:%02d%02d/%02d/%02d" // ,dts.h, dts.m, dts.s,dts.mo, dts.d, dts.y % 100); oledprint("%s",inDat); }QS+HIB setup
/* QSHIBbase.c September 28, 2015 Base station for IR comm and master clock. */ #include "simpletools.h" //<- Code size 8524 bytes #include "badgetools.h" //<- 15440 bytes - using badge_setup() #include "datetime.h" //<- 9248 bytes - using dt_start(&dts) //<- 16132 bytes - using badge_setup() and dt_start(&dts) // y mo d h m s datetime dts = {2000, 1, 1, 0, 0, 0}; // dts -> date, time (system) datetime dta, dtt; // Alarm and temp dates, times void menu(); void Get_time(); void Get_date(); void Setclock(); void Send_Clock(); int main() { // Add startup code here. //pause(1000); // badge_setup(); dt_start(&dts); //text_size(SMALL); //text_size(MEDIUM); print("Good Start\n"); //oledprint("%04d/%02d/%02d\n",dts.y, dts.mo, dts.d); //oledprint("%02d:%02d:%02d\n",dts.h, dts.m, dts.s); //printi("%04d/%02d/%02d, %02d:%02d:%02d\n", // dts.y, dts.mo, dts.d, dts.h, dts.m, dts.s); char inBuff[40]; while(1) { // Add main loop code here. print(">"); getStr(inBuff,40); if(!strcmp(inBuff,"help")) menu(); else if(!strcmp(inBuff,"time")) Get_time(); else if(!strcmp(inBuff,"date")) Get_date(); else if(!strcmp(inBuff,"setclock")) Setclock(); else if(!strcmp(inBuff,"sendclock")) Send_Clock(); else { print("Unknown Command\n"); } } } void menu() { print("Menu - help, \n"); } Get_time() { printi("%02d:%02d:%02d\n", dts.h, dts.m, dts.s); } void Get_date() { printi("%04d/%02d/%02d\n", dts.y, dts.mo, dts.d); } void Setclock() { printi("Enter Time\n"); printi("year: "); scan("%d", &dtt.y); printi("\nmonth: "); scan("%d", &dtt.mo); printi("\nday: "); scan("%d", &dtt.d); printi("\nhour: "); scan("%d", &dtt.h); printi("\nminutes: "); scan("%d", &dtt.m); printi("\nseconds: "); scan("%d", &dtt.s); dt_copy(&dts, &dtt); } void Send_Clock() { //printi("%04d/%02d/%02d/ %02d:%02d:%02d\n", //dts.y, dts.mo, dts.d, dts.h, dts.m, dts.s); //irprint("%04d\n%02d\n%02d\n%02d\n%02d\n%02d\n",dts.y, dts.mo, dts.d, dts.h, dts.m, dts.s); send("Got This\n"); }It might need some tuning, but here is a first cut at a battery voltage measurement function. It uses the info you reported earlier 4.17V with t = 01435. Temperature could be a factor, and there may be other realities that have to be compensated. So, let's go ahead and try this and find out what they might be...
#include "simpletools.h" #include "badgetools.h" #include "datetime.h" float calcVt(float batteryVolts, int decayMicros); float batVolts(float vt); float RC = 360000.0 * (1.0 / 100000000.0); float vt, vbat; int main() { badge_setup(); vt = calcVt(4.17, 1435); while(1) { vbat = batVolts(vt); text_size(LARGE); cursor(0, 0); oledprint("%1.2f V", vbat); pause(1000); } } float calcVt(float voltsBattery, int microsDecay) { float voltsThreshold, tDecay; tDecay = ((float) microsDecay) / 1000000.0; voltsThreshold = voltsBattery * (1 - exp(-tDecay / RC)); return voltsThreshold; } float batVolts(float voltsThreshold) { float voltsBattery, microsDecay; low(0); pause(1); microsDecay = ((float) rc_time(0, 0)) / 1000000.0; voltsBattery = voltsThreshold / (1 - exp(-microsDecay / RC)); return voltsBattery; }With your situation above, we don't know whether there's a bug in the app code, or in the library modifications.
How about if we start with something known to work on a pair of badges first. The examples below work on my pair of badges; please make sure they work for you too. If yes, then try the library mods again and switch to your QS + HIB. I'm assuming that means a QuickStart and Human Interface Board.
To reduce debugging, I started with "03 Send Data with IR.side", and "04 Receive and Store IR Data.side" from an unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder. Then added in parts from "Test datetime Library.side" and the irprint/scan stuff from a few posts earlier.
Andy
/* Send Time with IR.c */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" datetime dts = {2015, 9, 25, 2, 39, 35}; void main() { badge_setup(); dt_start(&dts); oledprint("IR Snd t"); text_size(SMALL); cursor(0, 4); oledprint("P17 = Send Time\n"); while(1) { int states = buttons(); if(states & 0b0100000) { rgbs(RED, RED); irprint("%04d\n%02d\n%02d\n%02d\n%02d\n%02d\n", dts.y, dts.mo, dts.d, dts.h, dts.m, dts.s); rgbs(OFF, OFF); pause(600); } } }/* Receive Time with IR.c */ #include "simpletools.h" // Include simpletools library #include "badgetools.h" // Include badgetools library #include "datetime.h" datetime dtt; int states; void main() // Main function { badge_setup(); // Call badge setup while(1) { clear(); // Menu text_size(LARGE); oledprint(" IR Rcv "); text_size(SMALL); cursor(0, 5); oledprint(" Receive-P27\n"); text_size(LARGE); while(1) // Wait for button press { states = buttons(); if(states) break; } if(states != 0b0000001) // Not P27?, try again { cursor(0, 0); text_size(LARGE); oledprint(" Try Again "); pause(1000); continue; // Back to while(1) } // P27 has to have been pressed to get to here clear(); oledprint("Ready for IR "); // Display ready for IR // Wait for IR message irclear(); // Clear ir com buffers memset(&dtt, 0, sizeof(datetime)); // Clear their variables while(1) { irscan("%d%d%d%d%d%d", &dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s); if(dtt.y > 0) { break; } } clear(); // Menu, what to do with data text_size(SMALL); cursor(0, 5); oledprint("%04d/%02d/%02d\n%02d:%02d:%02d:", dtt.y, dtt.mo, dtt.d, dtt.h, dtt.m, dtt.s); cursor(0, 7); oledprint(" OK-P25"); while((states = buttons()) == 0); // Wait for button press text_size(LARGE); // Act on button press pause(500); } }Yesterday I decided to take my Guest Badge out of its package, yes, the Badge had the brown sticky paper on the plastic OLED shield. It also had some writing on the paper, nothing like "peel me off", but it did make it obvious that it should be removed somehow. Again, a sharp knife to loosen up the paper somewhere in the corner edge of the plastic shield. The difference between the Staff and the Guest Badge, the Staff Badge did not have any writing on the brown paper. I assume mine was the one that got away with no writing on the brown sticky paper.
The Guest Badge is now doing a twenty four hour test, I have just the clock program running in its own COG. When the test time is up I will then check to see how well it is keeping time, with the new datetime program, and I will check the battery usage. So far the new datetime program is working just as well as the datetime lib that comes with the C libs.
An observation:
As I expand my usage of the Badge(s) and peripheral items(QS+HIB), it sure would be nice if the simpletools lib had some itemized sub libs. Yesterday I noticed that in order to use the QS+HIB, I did not find any tools, in an easy to implement fashion, to utilize the IR and later on, the access to the EEPROM for a comm session with a Badge(s). I guess the further you move along with the badgetools lib, the harder it will be, or least time consuming, when or if it is decided to itemize some of the functions into some manageable libs for use with other devices.
When you are using SimpleIDE, and you have your Badge plugged in, but not turned on, the COMx should have a number that is associated with your device. When I first plugged in the Badge, my Windows 7 program did go through an "installing driver" session. Since I am using my Windows 7 box, I am not sure if a Windows 10 setup would have any problem finding and installing a suitable driver.
Next up, I will give that battery voltage program that Andy developed, a try. I would like to have a piece of firmware, that maybe starts up on your Badge that displays a clock and maybe a button press that shows you the battery status.
Ray
footnote: QS = QuickStart, HIB = Human Interface Board, for the QuickStart.
The new Battery Voltage program, that Andy developed, worked as expected. A voltmeter reading was confirming the voltage that was displayed on the screen. Since the program is using the 4.17 and 1435 values, I guess that the values are valid?
My twenty four hour attempted run, came up short, the Badge was no longer showing the clock after ~21 hours.
Start:
Running the clock in its own COG which displays a constant time update on the OLED screen.
Battery voltage - 4.14V(settled volts)
Stop:
~21 hour duration.
Battery voltage - 3.4V
Recharge time - 3.4V to 4.17V, approximately 2 hours.
I guess, now I have a bottom limit for the battery voltage, for non intensive demand programs, I have a sense for when its absolutely necessary to plug in. As you start loading up the program with things like using the LEDs and other things, it becomes crucial to know the battery state. I guess the battery voltage program can be put in the clock COG, and maybe have a button that displays what the current voltage is. It also becomes a necessity to have some kind of auto clock update via the IR, I think a good temporary candidate could be the QS+HIB. Hmm a lot to think about.
Ray
I'm deep into another task just now, but just to add some support to your findings.... those runtime figures seem about right with what I found during trials. The battery itself also has a safety cutout level (little pcb inside the battery), to prevent the battery discharging too low and being damaged. I really cannot recall the specs at the moment, but I thought that was around 3.2V. Maybe 3.4V.
Do you have the grey "Parallax" branded battery, or another type?
Anyway... I must get back to task, but if you wish to attach a zip file with the code here, I'd be happy to run the same test and compare battery results later in the week. I just received some of the new Parallax batteries on Friday, so they need a good test anyway!
Michael.
The battery is what came with the Badge(s), not ready to start testing other batteries.
Ray
Here is a video of a large piece of Plexiglass. You will notice there is printing on one side, but blank on the other. I depends on which side Parallax cuts it, up or down. Then they peal the down side of the plexi and leaves the top side covered.
The OLED is powered by both 3.3V and VBATT.
3.3V from the same regulator powering the Propeller,
AND also directly to the battery voltage to power the display (as that needs higher voltage).
I'm not in a place I can check, but from memory the OLED specifies typical VBATT min is 3.5V. I'd say your findings are correct.
About the batts... sorry, what I meant was that Parallax were shipping some green or blue colored batteries prior to getting stocks of the grey Parallax branded batteries. If you had an early release badge, you might not have got the Parallax branded battery- and that may have had different specs. So I just wanted to make sure we were comparing the same battery- AND it seems we are!
I just did some more testing of the Battery Voltage program (Andy), running into a problem. The numbers, 4.17 and 1435 values, seem to work for my Staff Badge, but when I run the program on the Guest Badge, it is showing the wrong voltage.
The 4.17 and 1435 values, I got from testing the Staff Badge. I wonder, if each Badge, with the battery inserted has their own specific RTC value at the voltage measured by a voltmeter. I guess Parallax will have to verify this, they have multiple Badges and batteries to work with.
Ray
Essentially the rctime circuit involves 2 resistors and a capacitor. I'm sure we used 1% tolerance parts. You would ideally want to do a 1time calibration of each badge.
The value that came up was, @ 4.17V RTC was 1471. This number is quite a bit different than what the Staff Badge had, which was, @ 4.17V RTC was 1435.
Not sure how to interpret the data, is it the battery characteristics, or is it the Badge battery circuit characteristics, or both? Since I only have two badges and two batteries, I am not sure if this is just a fluke or is this something that needs a work around.
If it is the battery characteristics, RTC value changing for a specified voltage reading, with usage of the battery perhaps, then I guess a calibration or maybe some kind of maintenance firmware program would become a useful item to develop. This would probably become necessary due to the fact that the battery would have to changed out at some point, and of course the new battery would have its own RTC value, I think. So, are there batteries that have a common consistent RTC rating? Or, is it the Badge battery circuit, or both? Or, maybe it is neither, and I am just having a senior incident. :-)
Ray
However, for the sake of keeping this simple, we can say that the tolerance factor won't change once a badge is built. The tolerance is a factor of the components on the badge, and what I mean is that once those 1% or 5% parts are soldered into the badge, they are not going to change (unless the user changes them
So calibrating each badge ONCE at the start of it's life should be sufficient to measure any voltage (or therefore battery) connected now or later.
You probably (or Andy probably) used the value of the sense resistor and capacitor in the calculation (formula). The sense resistor may nominally be included as value 360K, but the tolerance is 1%. Therefore the actual value will vary on each badge in the approximate range: 356K to 364K. If you plug these min and max values into the same formula, you will probably find the resulting range of possible RTC values covers the readings you have experienced.
To calibrate, you might be comfortable just reading the sense resistor with a multimeter and adding that value to your code, or you might take some sample readings and caclulate an offset that way. The resistor in question will be the one giving you a value close to 360K over on the right of the Propeller chip, near to the RCT egg.
Does all this make any sense ? (excuse the pun!)
Edited: underlined text corrected.
The other thing that I noticed today, is the OLED displaying a previous oledprint() on the screen, even after the Badge is powered off. Does the OLED screen have some kind of memory associated with it?
Ray
Footnote: Tech = maybe an electrical engineer, or a plain old tech person. Or maybe a plain young tech person.:-)
That was mentioned in another thread. I only happens when the USB cable is plugged in, right? If so, that's normal.
EDIT: It was mentioned here:
http://forums.parallax.com/discussion/162020/badge-first-impressions
Ray, if you look at the schematic, U203 and possibly Q201 are always under battery power. U203 is for the electronic switch. Since it's not a physical switch, it needs power to sense the button push.
Hope that helps.
I set up my Staff Badge to be the sender, and my Guest Badge to be the receiver. Is there a listing of the binary numbers that are assigned to the buttons, all seven? Boy do I miss having a text_size(MEDIUM), maybe takes up two lines for the text size.
Ray
/* gIRtest.c October 6, 2015 * Guest Badge IR receive. */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" datetime dts = {2000, 1, 1, 0, 0, 0}; datetime dta, dtt; int states; void System_base(); void bLine(); int main() { // Add startup code here. badge_setup(); dt_start(&dts); text_size(SMALL); oledprint("Any BTN for Menu"); pause(300); cog_run(System_base,128); while(1) { // Add main loop code here. text_size(SMALL); while(!buttons()); cursor(0,0); bLine(); cursor(0,0); oledprint("Receive-P27 "); while((states = buttons()) == 0); switch(states) { case 0b0000001: //button P27 cursor(0,0); bLine(); cursor(0, 3); text_size(SMALL); oledprint("Waiting for IR"); cursor(0,3); oledprint("Ready for IR "); // Display ready for IR // Wait for IR message irclear(); // Clear ir com buffers memset(&dtt, 0, sizeof(datetime)); // Clear their variables while(1) { irscan("%d%d%d%d%d%d", &dtt.y, &dtt.mo, &dtt.d, &dtt.h, &dtt.m, &dtt.s); if(dtt.y > 0) { dt_copy(&dts, &dtt); cursor(0,0); bLine(); cursor(0,3); bLine(); cursor(0,6); oledprint("Got it "); break; } } continue; } } } void bLine() { oledprint(" "); } /* COG for running base utilty. */ void System_base() { while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,7); /* month day year, last two digits */ oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100); } }Help?
Referring back to the unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder, there's info in "Documentation badgetools Library.html" file; follow the button and buttons links in the Functions list. Also check the example programs in the "3 Buttons" folder.
In summary of those two resources:
When you call int state = button(number), number can be:
0 - (P27)
1 - (P26)
2 - (P25)
3 - (P15)
4 - (P16)
5 - (P17)
6 - (OSH)
state is 1 (pressed) or 0 (not pressed)
Example:
... cursor(0, 0); int state = button(4); if(state == 1) { oledprint("P16 ON "); led(4, ON); } else { oledprint("P16 OFF"); led(4, OFF); } ...When you call int states = buttons();
The states result will contain 7 bits, 0b0000000. The bits correspond to {OSH, P17, P16, P15, P25, P26, P27}. Example:
... int states = buttons(); if(states == 0b0000100) { oledprint("P25 ON "); leds(0b000100); } else { oledprint("P25 OFF"); leds(0b000000); } ...Note: If you expect to be responding to several different button press or combination possibilities, it's best to use the buttons function and capture them all at once. Then, go through with a series of if... statements or a switch... statement to decide what to do about the input.
Andy