By the way, I have not managed to get raw message exchange working over Bluetooth yet. I can send direct commands which do not require any response (eg. play tone) just fine, but those which require a reply does not work if sent as raw messages using write() and read(). Sending the command using the sendDirectCommand() function works though. I'm assuming that the message format remains the same for USB vs. Bluetooth, since there is no way to indicate which type of connection is to be used when calling send() or receive(). The Bluetooth protocol reference document does mention differences in the packet encoding over the air where 2 extra bytes are added as prefix, but if I tried to include those 2 bytes, the command (e.g., play tone) fails when sent using write().
tcwan, I'm having the same problem using write() and read() over bluetooth. I've also tried adding the extra bytes, but to no avail, I'm not sure what else to try.
afanofosc_99 wrote:Kami,
Can you tell me what you are passing into the viSetAttribute? I was stumped by the value that I saw in NISpy which seemed to be a session address or reference or something like that. Is it a brick resource string? If it requires a session address I am not sure how to get one from what I have via calls to the Fantom API functions. I haven't had a chance to dig any further into this, sadly.
John Hansen
John, I actually called viFlush instead of viSetAttribute, I couldn't quite figure out what to pass in as inputs for viSetAttribute and viFlush seemed to be what I was looking for. For viFlush, I cast the pointer to the nxt as a ViSession object, and that seemed to work. It has not, however, solved my problem of not being able to repeatedly poll a sensor during a single session, but that might be a topic for another thread, I'm not sure.
When I look at it, all the problems I have seem to be when I call read() and write(). I wonder if there are any alternatives to this, since sendDirectCommand() doesn't work when I need a response.
Kami