..... I am just wondering why Parallax did not put an RTC chip on the Badge? When some people, maybe somebody like myself, after they have gotten bored, they could always use the Badge like a clock. No, Parallax should not get into making digital watches.
Since the badge is hackable, it means you can put a hardware RTC on it.
Certainly Parallax could add a footprint for a RTC at almost no added cost.
Devices with Crystal Included and Compensation, like say NXP's PCF2129A, PCF2127A or the smaller & newer Epson RX8900SA
EPSON have some very good ppm/$ on RTC and TCXOs
On my last program, Guest Badge as a receiver, I noticed a slight problem, my time clock on the bottom lime is showing the wrong date.
Today I will have to figure out why the time part is working as expected, but the date part is not. I will a have to do some experiments with the buttons also, it seems when I try to implement an idea, it looks good on paper, but does not function as expected, in real time.
The other thing that I noticed was, it would be great if the timeclock function could be automated. Somehow, have it so when you present the Badge within an IR signal area, the timeclock would get updated without pushing any buttons for the procedure to occur. At this point, the Badge memory is about at the halfway point of being used so it seems like some tight code could get that automated sequence working. The next step, work out the bugs for the latest IR test and then see if I can work in the voltage thing.
We did look at RTC for the badge, but the rtc power backup cap was an issueissue- size and cost. And in the end we felt that would also make a nice add-on project for users.
That said... RTC still remains in our thoughts if we create a future badge
The stIRtest is the sender, gIRtest is the receiver. For the stIRtest program, once you load it then you have to start up a terminal program to plug in the values for the setclock function, then the program continues on.
For the gIRtest, you just load up the program, and the prompts on the OLED screen should guide you through the rest. This is all preliminary stuff, so don't cuss to much at the programs.
Now that I have been playing around with the softRTC, I am changing my mind about having a hardware RTC. My thinking, you will still have to have a specific program to set the RTC anyway. Since I am leaning more to an automated timedate update from an IR signal, which could be updated from the net or maybe a gps, this seems to be a workable solution. So, the heck with the hardware RTC.:-)
Something weird is going on, and I cannot seem to grasp it. When the System_Firm() COG is basically empty, then the program seems to run as expected. When I add an oledprint(), to the System_Firm(), then the program seems to run in an unexpected manner. Anybody have an explanation?
I'm assuming you are talking about the unexpected appearance of "Bottom line" at the top.
Since the main and System_Firm functions are running in separate cores, it looks like your code has an opportunity to duel over cursor position. The clear call in main places it at 0, 0, and the cursor call in System_Firm places it at 0, 7. These two processes happen asynchronously, so sometimes, System_Firm places the cursor at 0, 7, then main places it at 0, 0 with clear, then System_Firm prints "bottom line" and it appears at 0, 0, instead of 0, 7.
To avoid this type of problem, I generally have functions in many cores update information, but only one core does printing. Seriously, whenever possible, I use this approach.
The other approach would be to use locks. In the badgetools library, I used locks to prevent other cogs from triggering a screen update while one is already in progress, and also to prevent allowing more than one cog from interfering with each other on the I2C EEPROM/accelerometer bus. It can cause a cog that's waiting for a reply to wait forever because the chips on the I2C bus got confused by the signals from 2 different cogs interfering with each other by being sent simultaneously. This is an example of a "bus conflict".
All that said, here is an example of how to use locks to prevent the problem. Make sure to contain only the critical code that can get messed up with the lockset/lockclr. Using locks for too long can slow down other processes that are waiting for their turn.
volatile int myLock;
...
myLock = locknew();
// optional code to handle locknew returning -1 "all locks in use"
lockclr(myLock); // Initialize lock
...
while(lockset(myLock));
// Code that does a job that can only be accessed
// by one cog at a time here
lockclr(myLock);
...
while(lockset(myLock));
// Other code that does a job that can only be accessed
// by one cog at a time, presumably in function getting
// executed by a different cog.
lockclr(myLock);
We did look at RTC for the badge, but the rtc power backup cap was an issueissue- size and cost. And in the end we felt that would also make a nice add-on project for users.
That said... RTC still remains in our thoughts if we create a future badge
Allowing at least a footprint for a RTC seems simple.
The Epson RX8900SA I suggested has a easy-to-add lead pitch, (1.27mm gull wing) and includes the crystal, with a high degree of DTCXO precision. (1.9ppm 0~50'C)
The badge already has a battery, and RTC's can run down to sub 2V, so why not use that ?
The battery has a low voltage protection cutoff around 3V, plus the battery is removeable.
Yes, adding footprints seems simple. But maybe some customers will be concerned / upset about unpopulated parts?
RTC was seriously considered, but as always we have a larger picture to consider with all designs. There were probably >10 features we could have added... Where do we stop and get the product launched!!
RTC can be done in software, and can be added by the user as a good learning project. So the decision was made.
A quick reminder, I have changed my mind on the hardware RTC, I now favor a softRTC implementation.
Thanks Andy for the tutorial on lockset. Below, the program now has made use of the lockset scheme, and I also added a voltage reading. For a crude prototype, it works, at least for me. The voltage thing is still a device specific program, so you will have to get an RCT value for your device. Hopefully somebody could improve the voltage code so it works for all devices.
For a review, the P27 button sets up for an IR receive(update the clock), the P26 button now displays the battery voltage, and there is a continuous clock that is working on the bottom line.
The next thing to consider is an automated clock update scheme, not sure how to start with this one. Probably use the Staff Badge, for the testing, using maybe COG that would constantly send an ID code via IR and then on the Guest Badge, in a COG, it would be listening, via the IR, for an ID code, when received, let the sender know it has received it, and then go into a receive the update mode, or something along those lines. I need some ideas on this one.
There's a small and working time send/receive example on page 2. Start tinkering with those two programs and see if they can function in loops (instead of button controlled). This may take some additional code that looks for certain patterns. Not sure yet; try it and see what happens.
I cleaned up the program, from my last post, a bit, and now it runs a little closer to working as expected. Working with the button states and using the 'switch' loop feature, along with other running COGs, is a real pain, you can achieve coding disaster in a very few lines of code.
I think I would like to have the sender program moved over to my QS+HIB, but I am not sure how that is going to work out. I know a key part is to setup the IR, plus a working irprint() function. Not sure how many support functions are involved with irprint()?
The battery has a low voltage protection cutoff around 3V, plus the battery is removeable.
Yes, adding footprints seems simple. But maybe some customers will be concerned / upset about unpopulated parts?
RTCs are ok from 5.5V down so even a 3v cutoff is ok
Most attendees would have no idea it even had an unpopulated part, and for the total other end of the
scale, someone who was up to adding their own SMD part, would have no issues either.
The next thing to consider is an automated clock update scheme, not sure how to start with this one. Probably use the Staff Badge, for the testing, using maybe COG that would constantly send an ID code via IR and then on the Guest Badge, in a COG, it would be listening, via the IR, for an ID code, when received, let the sender know it has received it, and then go into a receive the update mode, or something along those lines. I need some ideas on this one.
That sounds like a great idea.
The staff Badge could be the one with RTC fitted, giving that 'reference time'.
A code-learning IR amplifier (see above) could even allow the master/slave to calibrate the slave 5 MHz crystal to the better-spec RTC.
A stable fixture and slightly longer timebase may even allow the Envelope-detect amplifier to calibrate crystal offset. 2ppm LSB is 2us per second, or 20us per 10 seconds.
I'm guessing the intent of the battery circuit was to give a rough idea of battery charge. This could be supported with a bar graph without requiring the voltage to match the voltmeter.
To display actual battery voltage for development purposes, the one-time voltmeter calibration Ray has commented on several times is one option for gathering somewhat more detailed info. Barring extra circuits on the prototyping area, it's needed because the logic threshold can vary considerably from one chip to the next, and tight RC part tolerances cannot compensate for that.
Circuits could be added to the prototyping area to eliminate the calibration requirement for more detailed info. For example, the current measurement technique could be refined by adding a voltage reference and comparator. Adding an ADC to the I2C bus would be another option.
The math for the calcCv and batVolts functions ignores the fact that the 1 k resistor forms a voltage divider with the 360 k during cap discharge. It's probably not going to make a difference to 2 sf over the range we are measuring.
Thinking more about the battery voltage measure, instead of showing an actual voltage number, maybe use the RGB LED to display Green Yellow Red scheme for some ballpark limits. This way one could get around everybody having to use a voltmeter and doing an RCT, to determine the initial values.
>4.0V - >=3.9V -> Green RGB, run for 3 seconds when called
'<'3.9V - >=3.7V -> Yellow RGB, run for 3 seconds when called
> 3.7V - >=3.5V -> Red RGB, run for 3 seconds when called
'<'3.5 -> Red RGB, always on, or maybe flashing. Possibly lock down the program till it gets recharged.
I think these numbers could cover every Badge, Also for the voltage function, maybe use 1453 as the RTC value. Not sure what the other Badges are showing for their numbers.
That would work. Another kinda fun way would be to have an image of a battery on the oLED, with four blocks to fill it up using "11 Shapes to Display.side" from "1 Display". As with the other examples, it's available after unzipping 20000-Badge-Propeller-C-Examples-Library-150918.zip to a folder.
Or, maybe since I am showing the time and date on the bottom line, put the voltage code in the COG, and then have a segmented bar where I am now showing the date. The segmented bar could start out being a dark grey which recedes to the left as the voltage goes down.
Before I move to something else, I think the command commit has to be rethought. For instance, when I press P27 button(receive IR), and commit to "Waiting for IR", what happens next if there is no IR signal, or the wrong IR signal comes in?
Once the command commit has been initiated, if you do not get an IR signal, then the program is locked, and the only solution is, hit the power button. What if on the sender Badge you hit the "Contact Info" button, what happens on the receiver Badge, when it is waiting for the datetime values? On the receiver end, at the moment the irscan() command is what is working, is there a setting for, maybe a time to wait value? Or is their another solution for getting out of the command commit situation.
At some point I will have to think about adding a button command to send information, or get information via the IR. This could get a little tricky with the IR signal interpretation if one Badge, is asking for one set of info, and a sender Badge is, by mistake, sending something else.
Even though I am thinking about automating the clock update solution, this command commit and correct IR signal comes in to play, big time. Some thoughts about this please.
The attached program now has the voltage read out on the bottom line along with the clock. I moved the voltage code to the clock COG, and now it runs the clock plus the voltage.
I also changed the RCT value to 1453, testing my two Badges, I show:
Staff Badge
Actual volt meter reading - 4.18V
Badge reading - 4.21V
Guest Badge
Actual volt meter reading - 4.07V
Badge reading - 4.04V
It looks like the 1453 value might work, for general usage. If some other people could try it out for their Badge, it would be interesting to see what kind of numbers you get.
Basically all you would have to do with the program is load it up, and the bottom line should show a running clock, and the voltage. Now if I could automate the clock update to run in the clock COG, that would eliminate a button command, and I would have a base unit that shows the time and the battery status, and then start developing the info exchange stuff.
Before I move to something else, I think the command commit has to be rethought. For instance, when I press P27 button(receive IR), and commit to "Waiting for IR", what happens next if there is no IR signal, or the wrong IR signal comes in? ... if you do not get an IR signal, then the program is locked, and the only solution is, hit the power button. ... Or is their another solution for getting out of the command commit situation.
In your unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder, study "05 Contact Manager (1).side" in the "6 Infrared Data" folder. All of its button options have return to main menu and/or back out paths in the code.
At some point I will have to think about adding a button command to send information, or get information via the IR. This could get a little tricky with the IR signal interpretation if one Badge, is asking for one set of info, and a sender Badge is, by mistake, sending something else.
Since I was having some problems with button control and a menu system, I decided that I needed a sort of starting point. The starting point is the program below, a Menu template program, hopefully this will be useful to other people.
It is a functional Menu program, which uses all of the buttons. From here you can delete, or comment out, what you do not need, and have a quick start up point. You have to remember that a lot of control code can be put in a case statement, so hopefully this will allow some control over the chaos.
Ray
/*
gDisplay.c
October 9, 2015
* A simple Menu template.
* Guest Badge Display control program when
using line (0,7) as a status line.
*/
#include "simpletools.h"
#include "badgetools.h"
#include "datetime.h"
int states;
void NewClear(); // Clears screen lines 0 - 6.
void bLine(); // Clean a line.
int main()
{
// Add startup code here.
badge_setup();
clear();
/* This constantly remains on line (0,7). */
text_size(SMALL);
cursor(5,7);
oledprint("Status line");
while(1)
{
// Add main loop code here.
/* Using continue in the switch statement
brings you back to this point. */
NewClear(); // Clear 0 - 6 and set cursor to (0,0)
text_size(SMALL);
cursor(0,0);
oledprint("Any BTN Menu ");
while(!buttons()); // No button press.
/* Menu setup. */
NewClear();
oledprint(" MENU ");
cursor(0,1);
oledprint("P17-button-P27");
cursor(0,2);
oledprint("P16-button-P26");
cursor(0,3);
oledprint("P15-button-P25");
cursor(0,4);
oledprint(" OSH ");
while((states = buttons()) == 0); // Wait for a button press.
switch(states)
{
case 0b0100000: //p17
cursor(0,7); // Use status line.
oledprint("B17 ");
continue; // Goes to the while(1)
/*********************/
case 0b0000001: //P27
cursor(0,7); // Use status line.
oledprint("B27 ");
continue; // Goes to the while(1)
/*********************/
case 0b0010000: //P16
cursor(0,7); // Use status line.
oledprint("B16 ");
continue; // Goes to the while(1)
/*********************/
case 0b0000010: //P26
cursor(0,7); // Use status line.
oledprint("B26 ");
continue; // Goes to the while(1)
/*********************/
case 0b0001000: //P15
cursor(0,7); // Use status line.
oledprint("B15 ");
continue; // Goes to the while(1)
/*********************/
case 0b0000100: //P25
cursor(0,7); // Use status line.
oledprint("B25 ");
continue; // Goes to the while(1)
/*********************/
case 0b1000000: //OSH
cursor(0,7); // Use status line.
oledprint("bOSH");
continue; // Goes to the while(1)
/*********************/
default:
continue; // Goes to the while(1)
}
}
}
/* To be used for clearing lines 0 - 6 */
void NewClear()
{
cursor(0,0);
bLine();
cursor(0,1);
bLine();
cursor(0,2);
bLine();
cursor(0,3);
bLine();
cursor(0,4);
bLine();
cursor(0,5);
bLine();
cursor(0,6);
bLine();
cursor(0,0);
}
/* Blanks a line. */
void bLine()
{
oledprint(" ");
}
I thought, maybe I need a program that has the basic Menu system, plus it should show me how my battery is doing. The program below shows the voltage on the status line, and you can play around with the buttons.
This program is using the, what I call, universal RCT value, so you should be reading a ball bark voltage value of the battery. Since nobody is reporting back on how the voltage gauge is working for you, I guess I can assume it's useful, or not.
Sorry, if you want to play along, you will need two Badges. Below is a sender program and a receiver program, I have a functional auto update scheme, that works.
On one badge, the sender Badge, basically it just sends out an IR signal waiting for a response. I have the program prompts on the Badge, for when to plug into a terminal program to plug in the datetime values. From there it just keeps sending an IR signal.
The receiver badge now uses a couple of functional buttons, so you can discover that yourself. Hopefully it will work as expected for everybody.
In the sender program, when you use irprint(), does the function automatically turn on, and off the left RGB LED? I thought, at first, that that activity would be draining the battery quickly, but it is not as bad as I thought.
Now the next step is to do some messaging between the two Badges, maybe the receiver Badge will have an ID that it can pass along to the sender Badge. Once the sender Badge gets the info it could store it in the EEPROM. Then the sender Badge could be improved to look up who used the datetime update an when.
I really think that the Badges need another device, as part of functional order of things, probably the QS+HIB, since the HIB has a built in IR facility. Once you get into the messaging, I do not think it would be very convenient if you had to write a program for every messaging item.
Oh, yes, this all done in PropGCC, using SimpleIDE. Hmm, wonder how all this would work in C++, maybe will have to wait for a P2 Badge.
Today I was testing my latest sender/receiver programs that I posted yesterday, and I notice I have picked up a very big lag, in the IR signal, between the two Badges.
My first code lines that I had, the two badges were going through the update process continuously, because there was not enough lag to turn the receiver Badge away, to break off the IR signal. Now it seems that, their is way too much time in the lag, you have to wait too long to sync up. There must be something I do not understand about the IR signal process. Also, how often do you have to use the irclear(), command?
I thought I had a workable concept here, but with so much lag time between sync up, I am not so sure. Any ideas on how to improve this?
I have started to design and implement a new experiment, my Staff Badge, hooked up to a Raspberry Pi. I have on numerous occasions mentioned that I need a device that would be able to update my clock that is running on my Guest Badge.
The Staff Badge may or may not be permanently attached to the RPi, will see if I will leave the battery in, or will be taken out. I will probably try to remove the datetime code, and have the Staff Badge updated by the clock that is running on the RPi. If I can get that far, then I will consider other things that Staff Badge can do while it is hooked up to the RPi.
I will keep this thread active, because further expansion of Guest Badge functionality will be looked at, and if it is useful enough I will describe it here, if anybody is still interested.
After doing some initial tests I am reconsidering going that route, using the RPi. I listed some of the problems, my interpretation, with using SimpleIDE for the RPi, in another thread, as one reason. The other observation I made is that RPi (the new Jessie version), likes to switch around the ttyUSBx attachments to the devices.
When I had the Staff Badge and the Propeller Platform board plugged in, they might start out with ttyUSB0 and ttyUSB1, then sometimes it gets switched around. So when you are trying to program with SimpleIDE, it gets to be a nice guessing game as to which one is which.
I may have to consider a Windows box for a semi-permanent Staff Badge attachment, and work with Windows for date time features, just to mention one item. Back to outlining possible implementations.
Comments
Very good idea.
Certainly Parallax could add a footprint for a RTC at almost no added cost.
Devices with Crystal Included and Compensation, like say NXP's PCF2129A, PCF2127A or the smaller & newer Epson RX8900SA
EPSON have some very good ppm/$ on RTC and TCXOs
Previously I wrote:
So calibrating each battery ONCE at the start of it's life should be sufficient
Should be:
So calibrating each badge ONCE at the start of it's life should be sufficient
Sorry for any confusion!
Today I will have to figure out why the time part is working as expected, but the date part is not. I will a have to do some experiments with the buttons also, it seems when I try to implement an idea, it looks good on paper, but does not function as expected, in real time.
The other thing that I noticed was, it would be great if the timeclock function could be automated. Somehow, have it so when you present the Badge within an IR signal area, the timeclock would get updated without pushing any buttons for the procedure to occur. At this point, the Badge memory is about at the halfway point of being used so it seems like some tight code could get that automated sequence working. The next step, work out the bugs for the latest IR test and then see if I can work in the voltage thing.
Ray
That said... RTC still remains in our thoughts if we create a future badge
For the gIRtest, you just load up the program, and the prompts on the OLED screen should guide you through the rest. This is all preliminary stuff, so don't cuss to much at the programs.
Now that I have been playing around with the softRTC, I am changing my mind about having a hardware RTC. My thinking, you will still have to have a specific program to set the RTC anyway. Since I am leaning more to an automated timedate update from an IR signal, which could be updated from the net or maybe a gps, this seems to be a workable solution. So, the heck with the hardware RTC.:-)
Ray
Ray
/* gBATtest.c October 7, 2015 *Battery Test for Guest Badge */ #include "simpletools.h" // Include simple tools #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 states; void System_Firm(); int main() { badge_setup(); //vt = calcVt(4.17, 1435); //<- Staff Badge vt = calcVt(4.17, 1471); //<- Guest Badge cog_run(System_Firm,128); while(1) { clear(); text_size(SMALL); while((states = buttons()) == 0); switch(states) { case 0b0000001: //button P27 vbat = batVolts(vt); text_size(SMALL); cursor(0, 0); oledprint("%1.2f V", vbat); pause(1000); break; case 0b0000010: //button P26 cursor(0,0); oledprint("Overight line"); default: continue; } } } void System_Firm() { while(1) { cursor(0,7); text_size(SMALL); oledprint("Bottom line"); pause(100); } } 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; }I'm assuming you are talking about the unexpected appearance of "Bottom line" at the top.
Since the main and System_Firm functions are running in separate cores, it looks like your code has an opportunity to duel over cursor position. The clear call in main places it at 0, 0, and the cursor call in System_Firm places it at 0, 7. These two processes happen asynchronously, so sometimes, System_Firm places the cursor at 0, 7, then main places it at 0, 0 with clear, then System_Firm prints "bottom line" and it appears at 0, 0, instead of 0, 7.
To avoid this type of problem, I generally have functions in many cores update information, but only one core does printing. Seriously, whenever possible, I use this approach.
The other approach would be to use locks. In the badgetools library, I used locks to prevent other cogs from triggering a screen update while one is already in progress, and also to prevent allowing more than one cog from interfering with each other on the I2C EEPROM/accelerometer bus. It can cause a cog that's waiting for a reply to wait forever because the chips on the I2C bus got confused by the signals from 2 different cogs interfering with each other by being sent simultaneously. This is an example of a "bus conflict".
All that said, here is an example of how to use locks to prevent the problem. Make sure to contain only the critical code that can get messed up with the lockset/lockclr. Using locks for too long can slow down other processes that are waiting for their turn.
Andy
Allowing at least a footprint for a RTC seems simple.
The Epson RX8900SA I suggested has a easy-to-add lead pitch, (1.27mm gull wing) and includes the crystal, with a high degree of DTCXO precision. (1.9ppm 0~50'C)
The badge already has a battery, and RTC's can run down to sub 2V, so why not use that ?
Yes, adding footprints seems simple. But maybe some customers will be concerned / upset about unpopulated parts?
RTC was seriously considered, but as always we have a larger picture to consider with all designs. There were probably >10 features we could have added... Where do we stop and get the product launched!!
RTC can be done in software, and can be added by the user as a good learning project. So the decision was made.
Hope that helps explain a bit better.
Thanks Andy for the tutorial on lockset. Below, the program now has made use of the lockset scheme, and I also added a voltage reading. For a crude prototype, it works, at least for me. The voltage thing is still a device specific program, so you will have to get an RCT value for your device. Hopefully somebody could improve the voltage code so it works for all devices.
For a review, the P27 button sets up for an IR receive(update the clock), the P26 button now displays the battery voltage, and there is a continuous clock that is working on the bottom line.
The next thing to consider is an automated clock update scheme, not sure how to start with this one. Probably use the Staff Badge, for the testing, using maybe COG that would constantly send an ID code via IR and then on the Guest Badge, in a COG, it would be listening, via the IR, for an ID code, when received, let the sender know it has received it, and then go into a receive the update mode, or something along those lines. I need some ideas on this one.
Ray
There's a small and working time send/receive example on page 2. Start tinkering with those two programs and see if they can function in loops (instead of button controlled). This may take some additional code that looks for certain patterns. Not sure yet; try it and see what happens.
Andy
I think I would like to have the sender program moved over to my QS+HIB, but I am not sure how that is going to work out. I know a key part is to setup the IR, plus a working irprint() function. Not sure how many support functions are involved with irprint()?
Ray
Most attendees would have no idea it even had an unpopulated part, and for the total other end of the
scale, someone who was up to adding their own SMD part, would have no issues either.
I think there is room for both
softRTC is fine for casual use, and a great way to get 'clock infrastructure', like below
That sounds like a great idea.
The staff Badge could be the one with RTC fitted, giving that 'reference time'.
A code-learning IR amplifier (see above) could even allow the master/slave to calibrate the slave 5 MHz crystal to the better-spec RTC.
A stable fixture and slightly longer timebase may even allow the Envelope-detect amplifier to calibrate crystal offset. 2ppm LSB is 2us per second, or 20us per 10 seconds.
To display actual battery voltage for development purposes, the one-time voltmeter calibration Ray has commented on several times is one option for gathering somewhat more detailed info. Barring extra circuits on the prototyping area, it's needed because the logic threshold can vary considerably from one chip to the next, and tight RC part tolerances cannot compensate for that.
Circuits could be added to the prototyping area to eliminate the calibration requirement for more detailed info. For example, the current measurement technique could be refined by adding a voltage reference and comparator. Adding an ADC to the I2C bus would be another option.
The math for the calcCv and batVolts functions ignores the fact that the 1 k resistor forms a voltage divider with the 360 k during cap discharge. It's probably not going to make a difference to 2 sf over the range we are measuring.
>4.0V - >=3.9V -> Green RGB, run for 3 seconds when called
'<'3.9V - >=3.7V -> Yellow RGB, run for 3 seconds when called
> 3.7V - >=3.5V -> Red RGB, run for 3 seconds when called
'<'3.5 -> Red RGB, always on, or maybe flashing. Possibly lock down the program till it gets recharged.
I think these numbers could cover every Badge, Also for the voltage function, maybe use 1453 as the RTC value. Not sure what the other Badges are showing for their numbers.
Ray
Ray
Once the command commit has been initiated, if you do not get an IR signal, then the program is locked, and the only solution is, hit the power button. What if on the sender Badge you hit the "Contact Info" button, what happens on the receiver Badge, when it is waiting for the datetime values? On the receiver end, at the moment the irscan() command is what is working, is there a setting for, maybe a time to wait value? Or is their another solution for getting out of the command commit situation.
At some point I will have to think about adding a button command to send information, or get information via the IR. This could get a little tricky with the IR signal interpretation if one Badge, is asking for one set of info, and a sender Badge is, by mistake, sending something else.
Even though I am thinking about automating the clock update solution, this command commit and correct IR signal comes in to play, big time. Some thoughts about this please.
Ray
I also changed the RCT value to 1453, testing my two Badges, I show:
Staff Badge
Actual volt meter reading - 4.18V
Badge reading - 4.21V
Guest Badge
Actual volt meter reading - 4.07V
Badge reading - 4.04V
It looks like the 1453 value might work, for general usage. If some other people could try it out for their Badge, it would be interesting to see what kind of numbers you get.
Basically all you would have to do with the program is load it up, and the bottom line should show a running clock, and the voltage. Now if I could automate the clock update to run in the clock COG, that would eliminate a button command, and I would have a base unit that shows the time and the battery status, and then start developing the info exchange stuff.
Ray
In your unzipped 20000-Badge-Propeller-C-Examples-Library-150918 folder, study "05 Contact Manager (1).side" in the "6 Infrared Data" folder. All of its button options have return to main menu and/or back out paths in the code.
Andy
It is a functional Menu program, which uses all of the buttons. From here you can delete, or comment out, what you do not need, and have a quick start up point. You have to remember that a lot of control code can be put in a case statement, so hopefully this will allow some control over the chaos.
Ray
/* gDisplay.c October 9, 2015 * A simple Menu template. * Guest Badge Display control program when using line (0,7) as a status line. */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" int states; void NewClear(); // Clears screen lines 0 - 6. void bLine(); // Clean a line. int main() { // Add startup code here. badge_setup(); clear(); /* This constantly remains on line (0,7). */ text_size(SMALL); cursor(5,7); oledprint("Status line"); while(1) { // Add main loop code here. /* Using continue in the switch statement brings you back to this point. */ NewClear(); // Clear 0 - 6 and set cursor to (0,0) text_size(SMALL); cursor(0,0); oledprint("Any BTN Menu "); while(!buttons()); // No button press. /* Menu setup. */ NewClear(); oledprint(" MENU "); cursor(0,1); oledprint("P17-button-P27"); cursor(0,2); oledprint("P16-button-P26"); cursor(0,3); oledprint("P15-button-P25"); cursor(0,4); oledprint(" OSH "); while((states = buttons()) == 0); // Wait for a button press. switch(states) { case 0b0100000: //p17 cursor(0,7); // Use status line. oledprint("B17 "); continue; // Goes to the while(1) /*********************/ case 0b0000001: //P27 cursor(0,7); // Use status line. oledprint("B27 "); continue; // Goes to the while(1) /*********************/ case 0b0010000: //P16 cursor(0,7); // Use status line. oledprint("B16 "); continue; // Goes to the while(1) /*********************/ case 0b0000010: //P26 cursor(0,7); // Use status line. oledprint("B26 "); continue; // Goes to the while(1) /*********************/ case 0b0001000: //P15 cursor(0,7); // Use status line. oledprint("B15 "); continue; // Goes to the while(1) /*********************/ case 0b0000100: //P25 cursor(0,7); // Use status line. oledprint("B25 "); continue; // Goes to the while(1) /*********************/ case 0b1000000: //OSH cursor(0,7); // Use status line. oledprint("bOSH"); continue; // Goes to the while(1) /*********************/ default: continue; // Goes to the while(1) } } } /* To be used for clearing lines 0 - 6 */ void NewClear() { cursor(0,0); bLine(); cursor(0,1); bLine(); cursor(0,2); bLine(); cursor(0,3); bLine(); cursor(0,4); bLine(); cursor(0,5); bLine(); cursor(0,6); bLine(); cursor(0,0); } /* Blanks a line. */ void bLine() { oledprint(" "); }This program is using the, what I call, universal RCT value, so you should be reading a ball bark voltage value of the battery. Since nobody is reporting back on how the voltage gauge is working for you, I guess I can assume it's useful, or not.
Ray
On one badge, the sender Badge, basically it just sends out an IR signal waiting for a response. I have the program prompts on the Badge, for when to plug into a terminal program to plug in the datetime values. From there it just keeps sending an IR signal.
The receiver badge now uses a couple of functional buttons, so you can discover that yourself. Hopefully it will work as expected for everybody.
In the sender program, when you use irprint(), does the function automatically turn on, and off the left RGB LED? I thought, at first, that that activity would be draining the battery quickly, but it is not as bad as I thought.
Now the next step is to do some messaging between the two Badges, maybe the receiver Badge will have an ID that it can pass along to the sender Badge. Once the sender Badge gets the info it could store it in the EEPROM. Then the sender Badge could be improved to look up who used the datetime update an when.
I really think that the Badges need another device, as part of functional order of things, probably the QS+HIB, since the HIB has a built in IR facility. Once you get into the messaging, I do not think it would be very convenient if you had to write a program for every messaging item.
Oh, yes, this all done in PropGCC, using SimpleIDE. Hmm, wonder how all this would work in C++, maybe will have to wait for a P2 Badge.
Ray
My first code lines that I had, the two badges were going through the update process continuously, because there was not enough lag to turn the receiver Badge away, to break off the IR signal. Now it seems that, their is way too much time in the lag, you have to wait too long to sync up. There must be something I do not understand about the IR signal process. Also, how often do you have to use the irclear(), command?
I thought I had a workable concept here, but with so much lag time between sync up, I am not so sure. Any ideas on how to improve this?
Ray
I'm going to split your display question into a new topic- could be really useful to find this in the future.
http://forums.parallax.com/discussion/162516/hackable-badge-custom-display-graphics
The Staff Badge may or may not be permanently attached to the RPi, will see if I will leave the battery in, or will be taken out. I will probably try to remove the datetime code, and have the Staff Badge updated by the clock that is running on the RPi. If I can get that far, then I will consider other things that Staff Badge can do while it is hooked up to the RPi.
I will keep this thread active, because further expansion of Guest Badge functionality will be looked at, and if it is useful enough I will describe it here, if anybody is still interested.
Ray
Yes please !
When I had the Staff Badge and the Propeller Platform board plugged in, they might start out with ttyUSB0 and ttyUSB1, then sometimes it gets switched around. So when you are trying to program with SimpleIDE, it gets to be a nice guessing game as to which one is which.
I may have to consider a Windows box for a semi-permanent Staff Badge attachment, and work with Windows for date time features, just to mention one item. Back to outlining possible implementations.
Ray