Timestamps

[Justin F. Knotzke]

   Just a quick update.

   I have timestamps working up until 512 bytes. ;-)

   The code uses a sorta wonky two buffer ping/pong approach. That's legacy from Sparkfun's firmware. When 1 512 buffer is filling, the other is writing. This is to ensure no data gets lost.

   So the timestamps are added up to 512 and when I switch buffers, they stop. It should be fairly easy to fix, but I figured I'd give you an update.

   I included the code here in case you want to debug it for me while I do actual paid work. ;-)

   J

[Justin F. Knotzke]

2010/1/8 Justin F. Knotzke <jkno...@shampoo.ca>

   Nevermind.. Found it. Plus Jim found a coupla little bugs. 

   So it's logging time stamps. The only thing I find weird is that I had it running for 10 seconds and the timestamp only moved 1 second.

   I'll check that out later.

   J

 

[Justin F. Knotzke]

   Time stamps appear to be working. They are updating correctly and I am able to parse. I will commit the code tonight when I get back home from the office.

   So, the message format is as follows:

   SYNC (0xa4) MSG_LENGTH, CHAN_NUM, DATA[x], CHECK_SUM, HOUR, MINUTE, SECOND

   Anyone with lots of years of embedded programming is probably cringing over this because I don't have a checksum for the entire record, only for the ANT message itself. To which I say to you: TOUGH!

   No seriously, I could, but if the ANT message fails, it gets discarded, including the time stamp. If the time stamp gets crunched, the ANT message is still intact and I could fake a time stamp based on a previous time stamp. 

   For now, this will do I think. If we come into problems, I can just extend HOUR, MINUTE, SECOND to include a timestamp at the end of that.. I don't want to muck with the ANT message format.

   Next thing is the LPC2148, which the Logomatic is based on has an onboard RTC. That RTC isn't by default hooked up to a separate power supply. Which is to say, if you turn off the board, your timer dies and when you turn it back on, your clock is now flashing 12:00 (sort to speak).

   I will set the time to Jan 1 2010 00:00:00 at startup. I only use hr,min,sec anyhow. I check for elapsed time from start.

   There is a way, apparently, to wire the RTC so that it always draws power from a battery if the board is on or not. I haven't looked this very closely. There are other options GPS, seperate time clock.. etc. All of which are out of scope for me at this point. Which isn't to say you can't look into it.

http://www.nxp.com/documents/user_manual/UM10139.pdf

   GC assumes 1 second sample rates. So merely supporting seconds is going to be good enough for now. When this is finished, and we import into GC. GC allows you to set the date and time when importing. Thus, you will manually enter date and time for your ride. Not perfect, but for the time being, good enough.

   Next step is getting the device ID and the device type. According to Paul, this can only be done after the device issues its first broadcast message.

   I didn't have any ANT+ logic in the firmware before the time stamp. Now I do. So, it will be easier to detect when the device has issued it's first broadcast. From there, I'll be able to detect the type and the ID of the device. 

   This leads me then to the next step which is power support and then multiple device support. 

   If all goes well, probably by the end of the weekend.

   J

[pa...@gch.sbrk.co.uk]

On Fri, Jan 08, 2010 at 11:16:43AM -0500, Justin F. Knotzke wrote:
> Time stamps appear to be working. They are updating correctly and I am
> able to parse. I will commit the code tonight when I get back home from the
> office.

I'm wondering if this is strictly necessary at all. Once you receive
your first broadcast, you will receive one every message period or
an RX fail. You need an initial timestamp for the first broadcast
and you could perhaps throw one in every so often as a fake ANT message.
Other than that, you just need to cound the broadcasts to determine
the time.

Paul

[Jim Ley]

2010/1/8 Justin F. Knotzke <jkno...@shampoo.ca>:

>    No seriously, I could, but if the ANT message fails, it gets discarded,
> including the time stamp. If the time stamp gets crunched, the ANT message
> is still intact and I could fake a time stamp based on a previous time
> stamp.

I think not losing the ANT message on time failure is a good thing
certainly, so a seperate checksum for whole message would be nice in
any case.

>    There is a way, apparently, to wire the RTC so that it always draws power
> from a battery if the board is on or not. I haven't looked this very
> closely.

This looked to be rather tricky, certainly I don't trust my hacking on
the board to be able to lift a pin.

>    Next step is getting the device ID and the device type. According to
> Paul, this can only be done after the device issues its first broadcast
> message.

Is this as simple as sending a MESG_REQUEST_ID (as it's called in
nant) and then leaving the parsing of the response to the Parser
later?

I guess one problem is that the period will need to change depending
on which device appears - what's the process for doing that? As I
thought the period was defined when you first started listening?

Definitely both happy and have time to help with these things over the weekend.

Cheers,

Jim.

[Justin F. Knotzke]

2010/1/8 <pa...@gch.sbrk.co.uk>

I'm wondering if this is strictly necessary at all. Once you receive
your first broadcast, you will receive one every message period or
an RX fail. 

    By "one" you mean a time stamp ? 

   J 

[pa...@gch.sbrk.co.uk]

On Fri, Jan 08, 2010 at 11:46:47AM -0500, Justin F. Knotzke wrote:
> 2010/1/8 <pa...@gch.sbrk.co.uk>
> > I'm wondering if this is strictly necessary at all. Once you receive

> > your first broadcast, you will receive *one *every message period or
> > an RX fail.

By "*one*" you mean a time stamp ?

No, I mean a broadcast. The way ANT works is that it will transmit the last
value sent every message period unless it is updated. i.e.
send("foo")
sleep(10)
send(bar")

is received as:
foo
foo
foo
foo
foo
..
bar
bar
bar
bar

And if you didn't receive abroadcast at the expected time, you'd
see a RX fail instead.

Paul

[Justin F. Knotzke]

2010/1/8 <pa...@gch.sbrk.co.uk>

No, I mean a broadcast. The way ANT works is that it will transmit the last
value sent every message period unless it is updated. i.e.

  Ah ok.. I'm reading:

pg 32 of the ANT Message Protocol:

"Once opened, the master‟s host provides ANT with data as it sees fit using the ANT_SendBroadcastData() message. Please note that the frequency at which the host provides ANT with new data may not be the same as the channel period. ANT will broadcast the data in its buffers at the desired message rate, if no new data is made available by the host, the previous data will be broadcast. However, appropriate safeguards to account for such repeated messages should be in place on the slave." 

   So there'd have to be logic to handle the above...

   J

[pa...@gch.sbrk.co.uk]

On Fri, Jan 08, 2010 at 04:39:49PM +0000, Jim Ley wrote:
> 2010/1/8 Justin F. Knotzke <jkno...@shampoo.ca>:

> > ?? No seriously, I could, but if the ANT message fails, it gets discarded,

> > including the time stamp. If the time stamp gets crunched, the ANT message
> > is still intact and I could fake a time stamp based on a previous time
> > stamp.

> > ?? Next step is getting the device ID and the device type. According to

> > Paul, this can only be done after the device issues its first broadcast
> > message.
>
> Is this as simple as sending a MESG_REQUEST_ID (as it's called in
> nant) and then leaving the parsing of the response to the Parser
> later?

Yes it is. And indeed I do exactly that in my ant library. As soon as
I see the first transmission on a channel, I issue the 0x51 request.
The application code doesn't even have to do that.

> I guess one problem is that the period will need to change depending
> on which device appears - what's the process for doing that? As I
> thought the period was defined when you first started listening?

You usually set the message period when you open the channel expecting
to see a device of a certain type that transmits at that message
period. However, if you want you can use any message period, open
the channel which does a search and is effectively ignoring the
message period, see what device type you find and then update
the message period. I expect though, that you'll probably have to
reopen the channel after doing that though as the ANT chip needs to
be clocked onto the new message period.

Paul

[pa...@gch.sbrk.co.uk]

Logic to handle what? There is logic on the slave (PC) for each
device profile to detect duplicates. i.e. the HRM profile uses
a sequence number and the other device profiles use values that
are cumulative and not absolute. But, you receive messages at
a constant rate, so just counting them tells you when you received
them.

Paul