Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

SEN is LOW => no ISR

RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hello everybody!

I'm using a PIC24F with ANT_AP2-module. I use synchronous mode.

Step 1 was to send messages to the ANT-USB-stick:
My node is the master and is transmitting only... it works.

Step 2 is to receive messages:
My node is slave and should receive only...

But it doesn't. No interrupt is genereted because SEN stays low. So I used a wire to pull it high(O_o) for a moment to get finally my interrupt on the falling edge of SEN. Then everything is fine and I receive the message once.

Also when I used my node as master for transmitting "SEN-idle" was low. When I pulled MSGRDY to GND, SEN was changing. So there it is no problem. But now?

What have I to do that SEN is high?
Or what other possibilities do I have?

Greets,
Matthias      
RankRank

Total Posts: 47

Joined 2010-07-08

PM

When you say "synchronous" do you mean byte synch or bit synch?

Also, if you have not already, please review the document "Interfacing with ANT General Purpose Chipsets and Modules" and make sure you are applying the proper initialization sequence for whichever mode you are applying:

http://www.thisisant.com/images/Resources/PDF/1204663102_interfacing with ant general purpose chipsets and modules.pdf

The SEN line is driven by ANT, so I am not sure I understand your problem.      
RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hello.

I use byte-sync mode.

"The SEN line is driven by ANT, so I am not sure I understand your problem."

My Problem is that this line, which is driven by ANT is low and I get no falling edge to trigger my ISR for receiving data from ANT.
But when I start my receive-routine without waiting for falling edge I receive the data which I transmit via the USB-stick. So I guess my configurations(on µC and ANTware) are ok.

When I only transmit, it is no problem, because when I pull MSGRDY low, SEN gets high and later again low and then everything is like in Fig.3-5 in "Interfacing...".

I have no idea what I can do that SEN is high!

Best regards,
Matthias      
RankRank

Total Posts: 47

Joined 2010-07-08

PM

That seems like a strange problem. Is the SEN line ALWAYS low? What if you reset the system / ANT chip - does it go high then? Does it ever go high?

Is it possible that maybe you have an incorrect pull up resistor or something like that? Can you share a schematic possibly?

Also, it would help to see some timing diagrams of the problem state, reset period, etc.

Best Regards,
Jefferson      
RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hello.

Thank you, Jefferson. The states were not the problems. First I didn't care much about what ANT wanted to tell me. Data received by ANT I just dumped. It worked for transmitting (I know: check EVENT_TX). In the pictures in the different manuals it seems to be that SEN has 2 Functions:
1.) kind of ACK when host wants to send and pulls MSG_RDY down!
2.) to show that ANT wants to transmit.

SEN seems to be idle high...

So my receive-function used the falling SEN-edge as interrupt, which never happend...

So I started to take care about the ANT Responses and used a state machine as adviced in the manual. But again no ISR, because SEN = 0.

Interesting:

"SEN will pulse after the synchronous reset sequence, but not necessarily after sending a command (such as the reset command). When SEN is high, it means that ANT is not ready to send/receive serial messages - it provides flow control.
Right after the reset command, ANT should be ready to receive messages from the host. Wait ~500ms after the command for the reset to be completed, and you should be able to start sending other commands." -alejandra
http://www.thisisant.com/component/option,com_fireboard/Itemid,146/func,view/catid,25/id,209/#308

"SEN needs to be on an interrupt capable I/O pin on the microcontroller." - ap2_transceiver_datasheet

However... Now I don't use an interrupt and I can receive too. In my opinion the datasheets could explain the things much better.

BG, Matthias