I’ve put this code up in a few other places, but posting here so that if I make any changes you can come here to see my progress.
I had some trouble getting some of the other example code for the nRF24AP1 working so I decided to work through it myself. I do not have it completely working yet but I do have the chip communicating and everything with my program so, its a good start!
I don’t know anything about Garmin HRM’s so this may be nonsense.
There’s a lot comes down to the ‘device profile’ of the sensor (in your case the HRM) and different equimpment manufactures have different profiles. As far as I can work out, the profile is a combination of the settings defined in section 5.2 in this document http://www.thisisant.com/images/Resourc … 0usage.pdf
I wanted to interface with Suunto, but they’ve opted to use a private network key rather than using the public network (ID=0) so without their co-operation, I’m stuck. To work out more than this, I think joining the ANT+ alliance will be required to get access to their reference designs and dev tools and I’m not sure I want to spend $500 just for a whim.
I’m my case I’m trying to fight my way past the Suunto helpdesk to talk to someone who knows what they’re doing but they are fending me off to date.
Garmin may be different, but you may also be doing everything right and just have the wrong key (or some other setting). If you’ve any information on the Garmin stuff post a link or chat me, I might opt to use that if this hurdle can be cleared.
Also getting it to work with Suunto should be no problem. Here are the differences between garmin and suunto
int gfreq = 0x39; // garmin radio frequency
int gperiod = 0x1f86; // garmin search period
int sfreq = 0x41; // suunto radio frequency
int speriod = 0x199a; // suunto search period
static uchar GARMIN_KEY[] = "B9A521FBBD72C345"; // Garmin
static uchar SUUNTO_KEY[] = "B9AD3228757EC74D"; // Suunto
Here is the raw output from the HRM:
RX: [sync]..[0x09]..[0x4e]..[0x00]..[0x58]..[0x60]..[0x36]..[0x18]..[0x4f]..[0x00]..[0x80]..[0x4d]..[0x77]
RX: msg received [12]
ID: Unknown [0x4e]
RX: [sync]..[0x09]..[0x4e]..[0x00]..[0x58]..[0x60]..[0x36]..[0x18]..[0x39]..[0x01]..[0x81]..[0x4d]..[0x01]
RX: msg received [12]
ID: Unknown [0x4e]
RX: [sync]..[0x09]..[0x4e]..[0x00]..[0x58]..[0x60]..[0x36]..[0x18]..[0x40]..[0x02]..[0x82]..[0x4d]..[0x78]
RX: msg received [12]
ID: Unknown [0x4e]
RX: [sync]..[0x09]..[0x4e]..[0x00]..[0x58]..[0x60]..[0x36]..[0x18]..[0x40]..[0x02]..[0x82]..[0x4d]..[0x78]
RX: msg received [12]
ID: Unknown [0x4e]
RX: [sync]..[0x09]..[0x4e]..[0x00]..[0x58]..[0x60]..[0x36]..[0x18]..[0x40]..[0x02]..[0x82]..[0x4d]..[0x78]
RX: msg received [12]
ID: Unknown [0x4e]
I’ve gotten “bored” and have since developed a uC based power meter based off several strain gauges. I thought it would be neat to interface this to my Garmin 705. Although I’m sure I could “fake” it to look like a HRM monitor and just use that as my power data, but it’d be much neater to send it as actual power data (since they support various power meters over ant+). Since I don’t have access to the developer area of the garmin doc for the SDK I wasn’t sure how the PM’s communicate with the unit. I assume the “device profile” is different from HRM’s anyone have any ideas or suggestions for this? It was somewhat related to this original post so I figured I’d ask here
I suppose even if knew the device profile I’d have to find out the network keys that garmin uses for that particular accessory :x
Glad to hear you nearly got success. I downloaded the sources (ant.tar.bz2) and tried to compiler but still failed. Can you suggest me what compiler should I use?
After a day or two strugeling to get anything working a week back I soldered pin headers on the two breakout boards I had not tryed this afternoon and went back to my breadboard setup. I had never suceeded in getting good coms with the board at all but with the threat of switching out the breakoutboards I got comunication straight away and managed to set up terminal macros to correctly recive from my garmin HRM. So a big step forward and a lot better understanding after manualy sending and reciving a load of messaged.
Has anyone actualy decoded the actual HRM data yet? I am hoping there will just be some period of some form in there, e.g. milicseconds between beats…
ellbiddy:
I’ve gotten “bored” and have since developed a uC based power meter based off several strain gauges. I thought it would be neat to interface this to my Garmin 705. Although I’m sure I could “fake” it to look like a HRM monitor and just use that as my power data, but it’d be much neater to send it as actual power data (since they support various power meters over ant+). Since I don’t have access to the developer area of the garmin doc for the SDK I wasn’t sure how the PM’s communicate with the unit. I assume the “device profile” is different from HRM’s anyone have any ideas or suggestions for this? It was somewhat related to this original post so I figured I’d ask here
I've just decoded the garmin power profile. If you're still interested, drop me a pm.
I’ve used the code from this thread to get started writing my own programming for working with the nRF24AP1 USB ANT Stick. I’m facing the same problem both in this code and in my own. After running the program, then exiting with ctrl-c, running it again fails to communicate. It hangs after the second packet (which is the first one expecting a response).
Has anyone else experienced this? Anybody have an idea?
ssnyde:
After running the program, then exiting with ctrl-c, running it again fails to communicate. It hangs after the second packet (which is the first one expecting a response)
You could try my code: git clone git://e2c3.com/nant.git
I’ve recently rewritten my ant library and it’s still work in progress, but it should work for a HRM or ANT+ power meter.
foo2.c:157: warning: integer constant is too large for ‘long’ type
Not a problem I think I found the issue. The problem only occurs on my laptop which runs kubuntu 9.10 kernel 2.6.31 which uses 1.5 of the ftdi driver. Everything works great on my desktop which is debian lenny kernel 2.6.26 with version 1.4.3 of the ftdi driver. I can’t be sure its not hardware but I think its the driver. At some point if I can find the source I’ll recompile 1.4.3 on the laptop but for now it’s all good.
foo2.c:157: warning: integer constant is too large for ‘long’ type
I wouldn't worry about foo*.c. They're just test programs that discover ANT network keys. Only network keys that comply with a certain algorithm are accepted by the set network key operation so I was curious as to how it is done. I've found about 400 of them and they seem to be constrained to a mask value and probably some bit count operations. Anyway, foo*.c need two USB keys to transmit and receive and also stress test the library. It sounds like unsigned long long isn't 64 bits on your laptop. Is it a 32 bit system and your desktop is 64 bit?
Hmm, yeah I was seeing the ctrl-c, not sending problem before. I haven’t don’t any work on the ant recently but I will look into sending some type of reset at the start will fix things.
