Creating a Blue tooth object and need a bit of general help using the - LMX9838

[grasshopper]

I am creating a blue tooth object for the propeller and I am running into a bit of translation problems.

I implemented the LMX9838 Bluetooth IC from national and its a great device, so far my PC sees it and my propeller can reset it. I understand that I need to send data using the SSP protocal that requires a start bit, stop bit, check sum, the data, and the proper opcode. This all needs to be sent using Hex.

Problem 1.
I am using the full duplex serial object and need to know if this is the correct way to send hex using a dat table



ser.str(@establishlink)
ser.str(@DataSend)

DAT
establishlink Byte "02530A38"
portdata Byte "31353535353531"




I guess I could do this but I wanted more structure.



ser.hex($02_53_0A_38,8)




Problem 2.
The data sheet states that the check sum as the calculated low bytes of the sum of all bytes(starting from Packet type to and including data length). How do I understand this. For example my Establish Link Request is as follows:



1 2 3 4 5 6..................... 7
$02_53_0B_38_31_35_35_35_35_35_31




This is translated as
1. $02 = start of text
2. $53 = Packet Type or request
3. $0B = Opp Code for establish link
4. $38 = data length
5. $31 = Local Port or port 1
6. $35_35_35_35_35 = Blue tooth address
7. $31 = Remote Device port

So to get the check sum I add $53+$0b+$38 = $96? I think this is OK please let me know what you think?

Post Edited (grasshopper) : 2/9/2009 11:17:34 PM GMT

[Mike Green]

The string functions (like ser.str) require a zero byte at the end of the data and the data itself can't contain a zero. You would need something like
establishlink Byte "02530A38",0

I don't think you really want to send any of the stuff you've shown in Problem 1. I think you really want the binary data like
establishlink Byte $02, $53, $0A, $38, 0

You're calculating the checksum ok, but keep in mind that the result is supposed to be only one byte, so it's really

($53 + $0B +$38) & $FF = $96

Also remember that the checksum (and maybe the data length) can have zero values. You would do better by using
ser.tx(<value>)
for any byte values that might possibly be zero.

[Mike Green]

Again, the Bluetooth device is unlikely to expect the data as hex character strings. I'm sure it's expecting the binary data, so you don't want the quotes around the hex strings. You want the Spin compiler to translate the hex strings to binary strings.

The embedded zero values will cause problems with the Bluetooth.str calls as you might expect.

If I were doing this, I'd put a length byte in front of the strings and write my own string output routine like:


A Byte 1, $01
B Byte 15, $02, $52, $69, $08, $00, $C3, $40, $5D, $C6, $00, $00, $C2, $01, $00, $03


and


PUB outputString(addr)
repeat byte[addr++]
Bluetooth.tx(byte[addr++])


then


Pub LMX9830_Initialisation(in)

{{LMX9830 Initialisation}}
{{Autobaudrate = 0}}
{{Set Clock and baudrate (13MHz ,$115200) = 1}}
{{Change Local BdAddr = 2}}
{{Enter BT Mode = 3}}

Case In
0 : outputString(@A)
1 : outputString(@B)
2 : outputString(@C)
3 : outputString(@D)

[VG]

Hi Grasshopper,
How did you connect the LMX9838 to prop? Any schematics that you can share??
Sincerely,
VG.

[rjo_]

http://www.national.com/appinfo/cp3000/files/SBK/AN1699_LMX9838SWUG.pdf

I know nothing about bluetooth but I am in your corner, because I have cobbled a microphone to my PropPhone and I am hoping one day to use bluetooth.

about the ","?

looks like "no" ... the protocol is described (p. 103) as a request/confirm loop... so I take it that after each command you send, you would wait for a reply.

I think this is going be a fairly popular subject a few months from now... any additional details would be deeply appreciated:)

Rich

[rjo_]

all ears!!!

[evanh]

grasshopper: Sounds like you've struggled to get your head around the data formats.

The terms Hex and Binary are interchangeable, hex just means a more readable view of raw binary data. So, you are meant to be sending raw binary data as commands out the comm port.

The printed commas are there just to show you the byte boundaries when transcribing it to your program.

The other common data format is ASCII (And now Unicode), used for text entry, where a number can be made up of a "string" of individual characters, one for each digit. People sometimes get confused that the text printout of a hex dump is the literal hex format. Not the case I'm afraid, it's just for convenience.

Hmm, hope that's intelligible.