Guidance needed in setting up a timing system

Projects General Guidance
1

Hi fellow coders,

I am, as my handle suggests, not long at this and I now find I need guidance as to how to proceed with a project I'm engaged on.

I have a timer under development, and I need a bit of guidance as to the path i'm to follow for the next phase of my coding.

Where I'm stuck is this:
The timer has many timing setup options.
For the sake of argument, and to give some idea of the complexity, let us specify them as:
Long, (single iteration or double iteration), (once or multiples(6, 12 or 24 times))
Shorter, (single iteration or double iteration), (once or multiples(6, 12 or 24 times))
Even shorter, (single iteration, double iteration), (once or multiples(6, 12 or 24 times))
And other variations that include flip/flopping players for 20sec apiece or 2 at once for 20,
and so on.
By (Long, Double, 12) I mean the clock will need to count down 10 sec, then from 4 minutes(Long) to zero( and that's 1 iter), reset with a 10 second interval to repeat the 4 mins(2nd iter) and then pause for a manual trigger to re-commence, and count up to 12 of those double iterations then end. You can work out the rest from that explanation I trust.

My concept is to use pre-programmed RFID cards with a reader on my control console to set variables for the current requirement - the options written on the card for ease of selection, and to be the go-to setup method for the user (most of whom will be non-tech), but also backed up with a 3 button / screen menu for situations where the cards are lost etc.

Now, as my coding skills are pretty rudimentary I'm sure I'll struggle with the whole variable setting and reading, so my plea for guidance.
I have managed to get the timer working on an STM32 and it's transmitting serial data to the screens wirelessly using HC-12 dohickeys - and I'm really chuffed at the progress so far.

Anybody interested in giving me a hand?
:stuck_out_tongue:

2

Sorry, no clue what you're trying to do, really.

Timing is normally done using millis(), and variables to hold a start time, an interval, and the iterations. So I guess something like this:

uint32_t startSequence;
uint32_t intervals[3];
uint8_t stage, totalStages;
uint8_t iter, totalIters;

void loop() {

// Starting the sequence
if (startSequence) {
  startTime = millis()
  stage = 0;
  totalStages = 3;
  intervals = {4*60*1000, 10*1000, 4*60*1000);
  iter = 0;
  totalIters = 12;
}
if (iter < totalIters) {
  if (handleCountDown()) {
    iter++;
    handleNextIter();
  }
}
// Rest of the loop() jobs.
}

bool handleCountDown() {
// handling the countdowns.
if (millis() - startTime > intervals[stage]) {
  startTime += intervals[stage];
  handleStage(stage);
  stage++
  if (stage == stages) {
    handleLastStage();
    stage = 0;
    return true;
  }
}
return false;
}
3

wvmarle:
Sorry, no clue what you're trying to do, really.

Timing is normally done using millis(), and variables to hold a start time, an interval, and the iterations. So I guess something like this:

Thank you for your kind reply vwmarle, good of you to take the time.

However, as I thought I had clearly stated in my request that I had the timer working successfully and transmitting data wirelessly to two screens I feel that the reply you give misses my query entirely.

OldManNoob:
I have managed to get the timer working on an STM32 and it's transmitting serial data to the screens wirelessly using HC-12 dohickeys - and I'm really chuffed at the progress so far.

Where I need guidance is in getting data off an RFID card and into the variables that set up the shootTime, the Details count, the shootEnds count (the number of rounds of either single or double iteration) and so on:

byte shootTime = 120; // Set start count value
byte shootEnds = 12; // Total number of Ends for competition
bool Details = true; // Single (false) or Double detail (true)
bool Practice = true; // Initially set as a practice round
bool shootDetail = true; // toggled for details AB or CD
const int hold = 10000; // set delay before detail change
byte Go = 0; // Starting buzzer first state
byte endCount = 1; // Ending state not reached
byte Walk = 10; // Default walkup period

I've attached my code so far as it goes - feel free to test it (stm32, LDP-6432-P7.62v2 led matrix driven by a PLT2001 matrix driver, and feel free to make suggestions.
I'm not a proud person but, when criticising my poor noob efforts, please do it constructively: ::slight_smile:

_2001Dev05OctLarge.ino (11.7 KB)

4

I'm not a proud person but, when criticising my poor noob efforts, please do it constructively:

I constructively suggest that you consider the following question:

What is the chance that someone on this forum

  1. has your exact hardware
  2. has the time and interest to load your program and test it, given zero documentation
  3. can use the experience gained thereby to figure out what question(s) you are asking?
5

:grin:

@jremington

I'm intrigued by: "has the time and interest to load your program and test it, given zero documentation"

What do you mean by zero documentation?

I have commented my code, quite extensively I thought - is this what you're referring to?

If not, you must be referring to the post, where I really had thought I had been clear.

Please try and rein in the sarcasm for a moment and consider this: I am a noob, no doubt about that, and I have stated this clearly.
If I am not clear in my explanation then say that and I will try really hard to explain further; but just engage with me, and I will be able to understand your point.
If my small code segment (uploaded) is indecipherable then say that and I will try to comment better.

Sarcasm, and patronising, are less than helpful. Do you not remember when you were struggling?

6

If you want help, please read and carefully follow the directions in the "How to use this forum" post.

7

Ok, @jremington, I have re-read that how-to post as you seem to feel I had not.

Now, armed to the teeth with the knowledge from it I have still little idea where you are finding fault with my post, but, in the interest of getting a little guidance as I stated in my original post let me recap on my project in case I was expecting too much understanding from too little explanation.

I am making a sport countdown timer.

The timer needs to count down from a number after a 10 sec lead in - the count down time has to be settable to be any one of 240s, 120sec, 80sec 40sec or 20 sec, depending on the current game being played.

The players are either in one wave or in 2 waves for each of these time sessions, each of which is called an END. i.e. the counter will either count (ignoring the lead-in for now) from 240 to zero once for the one wave of players or from 240 to 0 twice if there are two waves per end.

There are 6, or 12, or 24 of these ends in a full tournament.

During finals or playoffs there are other time periods:
Two players having alternating 20sec play periods, each one terminating the current count when he has played and commencing the count for the other at that moment.
or
two players having to share the same 20 or 40 sec period, playing simultaneously.

During team play there are even more options.

Now, my cry for help is not related to the timer function of the code, but how to best do the following:

Implement a card based setup, using an RFID reader, to take over from a standard menu so that non-technical users can easily set the right parameters without even thinking about it.

The reader should be able to fix the necessary variables in the console so that the timer functions as the card promises.
I need a little guidance in the approach I need to take in getting that to happen.

I hope this is a clearer explanation. :sweat_smile:

8

Implement a card based setup, using an RFID reader, to take over from a standard menu

This would be something for the Gigs & Collaborations section of the forum, where you might be able to hire help.

Before you post, I suggest to choose an RFID reader and be prepared to explain what it, and the menu, is supposed to do.

9

That latter explanation is a lot clearer in most areas.

In general, we respond a lot better to questions that say -
“this is what i’m trying to do, i have this working, but trouble with this part” - accompanied by details of the platform.

Unfortunately, the thread started off with -
“how do do this?”, providing a lot of detail, expectations, but not much background.

So it seems you have everything working, other than the RFID card reader to pull a specific operating configuration from a number of preset profiles.

If that’s the case, your problem is relatively simple.
You need to define your preset operating configuration somewhere FLASH, EEPROM etc (maybe as an array of structs),

A second array that binds RFID card numbers to an index in that struct array... so that when a card is scanned... the contents of struct[] is copied into the runtime variables.

Of course if you want to add/remove cards and change variable values - you’ll also need to consider an editor that lets you change things without recompiling and uploading every time.

10

Put that timing information in the RFID card - and of course make sure you have a card that's doing a lot more than just providing an ID.
The reprogramming would then be done by changing the info on the RFID card rather than on the Arduino side.

11

Put that timing information in the RFID card - and of course make sure you have a card that's doing a lot more than just providing an ID.

Why? I prefer @lastchangename's suggestion of holding the configuration data in EEPROM, and just use the card to make a selection.

Which is going to be easier to change? Program a new card with new information, or access the configuration and change it on the Arduino?

If the configuration profiles reside on the Arduino, you can develop program without the RFID.

For example, define 10 set up profiles. Figure out how to identify each profile (name, number?). What data types, are in each profile? How many total bytes of information. Organize that data in a struct. You will use the included eeprom library EEPROM.h and the functions EEPROM.put() and EEPROM.get() to save and retrieve the data. There is an EEPROM library example to store and retrieve a struct with mixed data types. Each profile will start at a known address.

You can start by calling the profile to use from the Serial monitor. Calling it with an rfid card should be a simple transition.

12

Of course it depends on the equipment OP has available, who does the reprogramming, how often it has to change, how predictable timing programs are, etc.

13

Which is going to be easier to change? Program a new card with new information, or access the configuration and change it on the Arduino?

I like my card = index suggestion - so that if a card is lost / stolen, it can be deleted/blocked in the controller.
Otherwise - a rogue card that is carrying valid data can be used to reconfigure the timers...
(Yes there are ways to manage this, but it's another layer of card management.)

14

True - but in the end whether solution is best depends on the actual application OP has for it, how the cards are used, etc.

I always find the lack of user interface (beyond the standard Serial, which is not even present in most ATtinys) the hardest part of dealing with Arduinos and related embedded devices, especially when it comes to inputting larger amounts of data, such as this timing table.

15

True dat'

16

wvmarle:
Put that timing information in the RFID card - and of course make sure you have a card that's doing a lot more than just providing an ID.
The reprogramming would then be done by changing the info on the RFID card rather than on the Arduino side.

That was where my thinking had been heading vwmarle, until lastchancename weighed in with the suggestion that the data should be kept on the device and accessed by the card.
This is more what I need, most likely, as the timing parameters are pre-defined by the rules of the sport and, aside from being added to for unusual events, will remain so for the foreseeable future.
In a competition, the settings can be expected to change a few times; qualifiers, knockouts, semi-finals and finals. Team events, of various flavours, would also often feature. This is why a card-based system appealed to me, and what prompted me to head down this route was watching a judge at one event struggle with deep menus as he attempted to set up what could have been a simple event.

I had originally conceived of the timing variables being on the card, pulling them off for a particular event as needed (card for qualifiers, followed in due course by the next card in line for the knockouts etc), which would allow me to add timing setups by no more than programming cards and distributing them to the clubs.
But what if the card is corrupted (likely?) or lost in the pocket of the previous user, or simply not the right cards for any of the current need? In this case a menu on board permitting the user to do the needed setup would come in to play. This, of course, implies that the data are contained on the system anyway.

So, lastchancename, I thank you for the input.

wvmarle:
Which is going to be easier to change? Program a new card with new information, or access the configuration and change it on the Arduino?

I do feel there's merit in this, albeit not as meant by vwmarle. :wink: If the timing systems are deployed and the needs change, then it would be far easier for me to alter a set of cards and deploy them than to the units than recall, reprogram and re-deploy.

Perhaps a combination of the two?
If I have a basic database of setups on the unit, accessed by a menu, and a reader which would ignore that database and setup the timer independently?
This could work, giving the best of both worlds.

17

You just mentioned previously seeing an official struggling with deep menus etc...
You could simplify everything by simply replacing the RFID card ‘index’ - with a simple thumbwheel, or keypad to select the timing profile.
Dial in the profile, and it’s ready to go.
If it has to be secure, make the selection method hidden, or detachable (so someone can lose it,)

BTW nothing says the profiles structs have to be hard coded... they could also live in EEPROM or ext memory, along with a method to edit the profiles, just like you need to pair or delete a card index to a specific profile.

18

OldManNoob:
But what if the card is corrupted (likely?) or lost in the pocket of the previous user, or simply not the right cards for any of the current need?

Part of the appeal of RFID is that it's so cheap that tags can be disposable (especially the very simple ones that are basically an electronic bar code), so that should not be too much of a problem. Another simple way of making sure you get back the cards is to have the players pay a deposit of a convenient amount (as in a single smallish note of your currency).

If you have a mostly fixed and limited set of timings, then indeed it makes sense to hard code them on the Arduino. In that case you can probably use the electronic bar code idea: that contains a number big enough to store player ID and timing set and maybe some other info.

I assumed it'd be more of a case by case basis - then you'd probably need a bit more complex an RFID with sufficient memory for your timing (but with some smarts, you can store lots in information in just 32 or 64 bytes - especially if you go bit-level rather than byte-level you can gain lots of efficiency: store start and stop time in a single byte, for example). In that case you also need a more complex system (a laptop maybe) where you can conveniently enter the custom timing table and store it on the card using a regular programmer.

19

I see where you're going Vvwmarle, but let me correct a misapprehension first.

The timer would be in the care of a single official during any day's gaming, and he alone would be in charge of all of the kit - at no time would any player be required to handle the cards, nor the timer, so the question becomes one of whether the official benefits from the ability to rapidly alter the parameters of the timer between one state of play and the next and not one of security.

To this end I've probably settled on the idea that I'll approach the design as a hybrid, which will allow the user to dig in to a menu if he/she desires/needs, but where the rfid card, containing all the parameters for a particular setup, would obviate the need to do so.
This would also permit me to update the timing systems already deployed without having to get my hands on them. Bonus.

One question I still have: What is the likelihood of cards getting corrupted? I cannot find much in the way of information on this topic that doesn't talk about hammers and microwaves. I'm of the impression that the cards, once written, remain reasonable stable unless intentionally harmed.

wvmarle:
Part of the appeal of RFID is that it's so cheap that tags can be disposable (especially the very simple ones that are basically an electronic bar code), ...
...you can gain lots of efficiency: store start and stop time in a single byte, for example).

That byte-level access appeals. And, lastchancename, arrays of structs - yes.

Ho hum - lots more to learn for this old dog :astonished:

20

AFAIK they're very stable indeed - little to no chance of things getting corrupted.
They have to be - if not stable and reliable, it'd be a headache to use them in just about any application! But then, we used to use floppy disks as well...