What that means is that you can send at most 1 data value per second. If you don't want to you can send only when the value changed (smart).
I'm not sure how can you do that with the rep number. It's not what you mean I guess, but the closest I can think of is that you zero out the counter in each set, and every time you detect another repetition you call fitField.setData with the new rep count, this will give you a graph with ta saw shape:

  /|.     /|.       /
 / |.    / |.      /
/  |__/. |___/

Nick said:

If I am graphing a field value, I noticed it says Apps are limited to 256 total bytes per message. 

If passing Numbers with one decimal, how do I figure out the byte number use?

Actually, a Number in Monkey C is 32 bits (4 bytes), and represents an integer ranging from -2,147,483,648 to 2,147,483,647, so decimals aren't applicable here. However, as far as FIT file recording goes, you actually have the choice of using 8 bits, 16 bits, or 32 bits for integers, depending on the range of values you need to write (more on that later).

If you want to graph a decimal value, Monkey C has 2 floating-point types: Float (32 bits / 4 bytes) and Double (64 bits / 8 bytes). Both of these types are available for FIT file recording.

The actual recorded type / number of bytes is determined by the 3rd argument to ActivityRecording.Session.CreateField() (type). The available values are listed here:

https://developer.garmin.com/connect-iq/api-docs/Toybox/FitContributor.html

DataType

Since:

API Level 1.3.0

To explain these types:

- SINT8 = signed 8-bit (1 byte) integer. Use this for a Number between -128 and 127

- UINT8 - unsigned 8-bit (1 byte) integer. Use this when you have a Number between 0 and 255

- SINT16 - signed 16-bit (2 byte) integer. Use this for Numbers between -32768 and 32767

- UINT16 - unsigned 16-bit (2 byte) integer. Use this for Numbers between 0 and 65535

- SINT32 - signed 32-bit (4 byte) integer. Use this for Numbers between -2,147,483,648 and 2,147,483,647

- UINT32 - unsigned 32-bit (4 byte) integer. Use this for Numbers between 0 and 4,294,967,295

- STRING - N/A to numbers

- FLOAT - single precision floating point (32 bits or 4 bytes). (Good for roughly 7 decimal digits.) Corresponding Monkey C type is Float

- DOUBLE - double precision floating point (64 bits or 8 bytes). (Good for roughly 15 decimal digits.) Corresponding Monkey C type is Double

TL;DR If you want to write a decimal value, you have to use at least 4 bytes, but probably no more than that (7 decimal digits should be more than enough.)

If you can somehow represent your value as an integer (maybe by multiplying the value by 10 before writing it, to simulate a fixed precision decimal value), then you could go as low as 2 bytes. (Of course this may not be an option if the app isn't just for personal use)

If your value is always between 0 and 255 (or -128 and 127), you can get away with using 1 byte.

Having said all of that, I have no idea if a device app could actually write 255 fields even if each field was only 1 byte. (I've never tried it)

Thank you. 

In my case, I am wanting to graph data, that is in fact summary data because it occurs sporadically, like for example, how many times a person kicks a football in a fotball match... they can go 20 minutes with nothing and then have 10 kicks in 3 minutes.

at the moment I am storing the array of values. Is there a way at the end of the session that I can add these values to a graph, ( but still have the session data record over say an hour or so for the rest of the session info?...... OR do I have to add these values as they are detected and occur during as session, which I could also do, but I'm worried about what the graphs would look like? 

Ok, and to confirm where it says per message. I am guessing that 1 message = 1 graphs total data?,  or is 1 message a single reading of the graph?

if it's enough to count the events per lap or per session then you can report it in a lap/session type field. If you want to have a graph with time on the x axis, then you'll have to report 0 every second, and 1 (or any number you feel like) for at least 1 second (or more if it makes sense). Then you'll have something like:

______-_-____---___-__

A message is a chunk of data written to the FIT file, corresponding to the entire session, a single lap, or a single point in time.

It consists of all the fields which are relevant to that message type, as specified in createField().

https://developer.garmin.com/connect-iq/api-docs/Toybox/FitContributor.html

Module: Toybox.FitContributor

Overview

Nick said:

OR do I have to add these values as they are detected and occur during as session

Yep, you have to write data in real time (or more accurately, call FitContributor.Field.setValue() in real time). The distinction is that setValue() doesn't write anything, it sets the next value to be written. (So if you call it more than once per second for MESG_TYPE_RECORD, for example, only the last value set before the actual write operation will be used.)

In the case of MESG_TYPE_LAP, you have to call setValue() *before* the lap is triggered, which means that lap values have to be continuously calculated. In the MoxyField SDK sample, the code for calculating session, lap and record data calculates all 3 of them continuously (once per second). (Technically speaking, you don't have to continuously call setValue() for session data, since in this case, it's enough to call it in onTimerStop(), since that event always has to happen before an activity is ended and saved.)

Thanks, 

So If I don't write the data every second, will that cause a graph without data?  or does it remain at the last set value until it's changed again? 

Once you called set data for the first time it'll always be on the last value set