I'm using a Bluesentry bluetooth device with an accelerometer attached to it. I want to receive data from it in MaxMSP but it isnt working. With Hyperterminal it works fine, I get a string of Hex data. I have the [Llong] object to convert hex data to decimals, but it doesnt seem to help. The Bluesentry is acting as a Virtual COM port, and it seems to connect well with the [serial] object. The only thing is, I'm not getting any output. I use the [serial] help file to test this, the only thing I get printed are the numbers 63, 13 and 10.

Hi,
I'm using a Bluesentry bluetooth device with an accelerometer attached to it. I want to receive data from it in MaxMSP but it isnt working. With Hyperterminal it works fine, I get a string of Hex data. I have the [Llong] object to convert hex data to decimals, but it doesnt seem to help. The Bluesentry is acting as a Virtual COM port, and it seems to connect well with the [serial] object. The only thing is, I'm not getting any output. I use the [serial] help file to test this, the only thing I get printed are the numbers 63, 13 and 10.

bluesentry-in-maxmsp

Here's an FAQ article which hasn't been posted yet. It should answer 

your question. Where PICBASIC DEC Formatter appears, substitute with 

> I'm using a Bluesentry bluetooth device with an accelerometer 

> attached to it. I want to receive data from it in MaxMSP but it 

> isnt working. With Hyperterminal it works fine, I get a string of 

> Hex data. I have the [Llong] object to convert hex data to 

> decimals, but it doesnt seem to help. The Bluesentry is acting as a 

> Virtual COM port, and it seems to connect well with the [serial] 

> object. The only thing is, I'm not getting any output. I use the 

> [serial] help file to test this, the only thing I get printed are 

---++ I'm using the Max serial object with (your hardware here). I 

understand that the Max serial object only supports numbers between 0 

and 255. The thing is, I'd like to use values greater than 255. 

Although the Max serial object is limited to 8-bit unsigned chars (0 

- 255), there are a couple of ways to use it to resolve larger 

numbers. As my experience with serial hardware is mostly limited to 

the Parallax Systems Basic Stamp, references here will be to that 

hardware, and the PICBASIC language used to program it.

There are really 2 issues: format and data parsing. Let's deal with 

On a Basic Stamp, data is sent over the serial pins as a series of 

bytes. The format you've chosen for the data determines how it will 

arrive in Max. Here are two examples of PICBASIC programs 

illustrating two typical formatting methods:

' We need to use a WORD-sized var (0 - 65535)

In the above example, PICBASIC's DEC formatter is used.

' SEROUT 16, 16468, [myVar.HIGHBYTE, myVar.LOWBYTE]

(Listing 2: Separating a 2-byte number into its components)

In the above example, we manually separate a WORD into two BYTEs.

Let's start with Listing 1. I've gotten a few bug reports from 

Windows users, claiming that HyperTerminal (

htpe/index.html) properly reports large numbers as received from 

their Basic Stamps, whereas Max only receives garbage. This reflects 

a misunderstanding of how PICBASIC's DEC formatter is working.

The PICBASIC DEC formatter _spells_ the number in ASCII values. This 

means that, when sending the number 256 (which, sent as 2 bytes, 

would be [1, 0]), it sends the 3 bytes [50, 53, 54]: "2", "5", "6"! 

Which explains why HyperTerminal is able to display the value.

To correctly parse this data in Max, we need to make a patch that 

will take an arbitrary number of incoming bytes and "unspell" the 

bytes into a numerical value. Such a patch can be found here.

Listing 2 is simpler to deal with. In our PICBASIC program, we've 

broken the WORD variable into two BYTE-sized chunks: HIGHBYTE and 

LOWBYTE. If we view a number as a hexadecimal value, the meaning of 

HIGHBYTE and LOWBYTE should be clear. For instance, the number 513, 

can be represented as hex: 0x0201. HIGHBYTE is 0x02, or 2 decimal. 

So, Max receives a sequence of values [2, 1], and merely needs to 

reconstruct the original number by shifting the first number 1 byte 

(8 bits) "to the left" and then add the second number to that. A 

So, we've managed to get our data into Max. However, in the real 

world, we're not dealing with a single value, but rather a stream of 

them. Assuming that we're using the formatting style of Listing 2, 

the sequence [2, 1, 6, 7, 1, 10, 3, 25] could mean 2 different 

things, depending on where we start pairing numbers. In order to 

correctly interpret incoming data, we have to know where the data 

starts and stops. Here's a variation of Listing 2, which adds a pair 

of divider bytes between a group of values.

DEBUG mySeparator.HIGHBYTE, mySeparator.LOWBYTE

We've determined arbitrarily that once every 12 values, a separator 

should be sent. We can program our patch so that no data will be 

accepted until an initial separator is encountered. After that, 

additional separators will be used to make sure that we haven't 

missed a byte somewhere along the way. Here's a simple patch which 

Note that we've had to make a small compromise: values which begin 

with HIGHBYTE 0xFF cannot be used, because they create a parsing 

ambiguity. This means that decimal values 65280 - 65535 are off- 

Here's an FAQ article which hasn't been posted yet. It should answer  
your question. Where PICBASIC DEC Formatter appears, substitute with  
"Bluesentry Formatter".

>
> Hi,
> I'm using a Bluesentry bluetooth device with an accelerometer  
> attached to it. I want to receive data from it in MaxMSP but it  
> isnt working. With Hyperterminal it works fine, I get a string of  
> Hex data. I have the [Llong] object to convert hex data to  
> decimals, but it doesnt seem to help. The Bluesentry is acting as a  
> Virtual COM port, and it seems to connect well with the [serial]  
> object. The only thing is, I'm not getting any output. I use the  
> [serial] help file to test this, the only thing I get printed are  
> the numbers 63, 13 and 10.
>
> Is there someone who has a solution?

---++ I'm using the Max serial object with (your hardware here). I  
understand that the Max serial object only supports numbers between 0  
and 255. The thing is, I'd like to use values greater than 255.  
Whatever can I do?

Although the Max serial object is limited to 8-bit unsigned chars (0  
- 255), there are a couple of ways to use it to resolve larger  
numbers. As my experience with serial hardware is mostly limited to  
the Parallax Systems Basic Stamp, references here will be to that  
hardware, and the PICBASIC language used to program it.

There are really 2 issues: format and data parsing. Let's deal with  
them in order.

On a Basic Stamp, data is sent over the serial pins as a series of  
bytes. The format you've chosen for the data determines how it will  
arrive in Max. Here are two examples of PICBASIC programs  
illustrating two typical formatting methods:

' This program loops from 0 to 1024 in
' order to demonstrate the DEC formatter

' We need to use a WORD-sized var (0 - 65535)
myVar VAR WORD

Main:
FOR myVar = 0 TO 1024
DEBUG DEC myVar
' Equivalent to:
' SEROUT 16, 16468, [DEC myVar]
NEXT
GOTO Main

' This program loops from 0 to 1024 in
' order to demonstrate separation of a
' WORD into two BYTEs

Main:
FOR myVar = 0 TO 1024
DEBUG myVar.HIGHBYTE, myVar.LOWBYTE
' Equivalent to:
' SEROUT 16, 16468, [myVar.HIGHBYTE, myVar.LOWBYTE]
NEXT
GOTO Main

Let's start with Listing 1. I've gotten a few bug reports from  
Windows users, claiming that HyperTerminal (http://www.hilgraeve.com/ 
htpe/index.html) properly reports large numbers as received from  
their Basic Stamps, whereas Max only receives garbage. This reflects  
a misunderstanding of how PICBASIC's DEC formatter is working.

The PICBASIC DEC formatter _spells_ the number in ASCII values. This  
means that, when sending the number 256 (which, sent as 2 bytes,  
would be [1, 0]), it sends the 3 bytes [50, 53, 54]: "2", "5", "6"!  
Which explains why HyperTerminal is able to display the value.

To correctly parse this data in Max, we need to make a patch that  
will take an arbitrary number of incoming bytes and "unspell" the  
bytes into a numerical value. Such a patch can be found here.

Listing 2 is simpler to deal with. In our PICBASIC program, we've  
broken the WORD variable into two BYTE-sized chunks: HIGHBYTE and  
LOWBYTE. If we view a number as a hexadecimal value, the meaning of  
HIGHBYTE and LOWBYTE should be clear. For instance, the number 513,  
can be represented as hex: 0x0201. HIGHBYTE is 0x02, or 2 decimal.  
LOWBYTE is 0x01, or 1 decimal.

So, Max receives a sequence of values [2, 1], and merely needs to  
reconstruct the original number by shifting the first number 1 byte  
(8 bits) "to the left" and then add the second number to that. A  
patch which does that can be found here.

So, we've managed to get our data into Max. However, in the real  
world, we're not dealing with a single value, but rather a stream of  
them. Assuming that we're using the formatting style of Listing 2,  
the sequence [2, 1, 6, 7, 1, 10, 3, 25] could mean 2 different  
things, depending on where we start pairing numbers. In order to  
correctly interpret incoming data, we have to know where the data  
starts and stops. Here's a variation of Listing 2, which adds a pair  
of divider bytes between a group of values.

' set mySeparator to 0xFFFF
mySeparator = 65535

IF myVar // 12 = 0 THEN
DEBUG mySeparator.HIGHBYTE, mySeparator.LOWBYTE
ENDIF

DEBUG myVar.HIGHBYTE, myVar.LOWBYTE
' Equivalent to:
' SEROUT 16, 16468, [myVar.HIGHBYTE, myVar.LOWBYTE]
NEXT
GOTO Main

We've determined arbitrarily that once every 12 values, a separator  
should be sent. We can program our patch so that no data will be  
accepted until an initial separator is encountered. After that,  
additional separators will be used to make sure that we haven't  
missed a byte somewhere along the way. Here's a simple patch which  
illustrates the concept.

Note that we've had to make a small compromise: values which begin  
with HIGHBYTE 0xFF cannot be used, because they create a parsing  
ambiguity. This means that decimal values 65280 - 65535 are off- 
limits using this system.

I tried those patches out, but I don't really understand how they will solve my problem. My knowledge of these serial ports and hex data etc. is unfortunately very limited.

Jeremy,
I tried those patches out, but I don't really understand how they will solve my problem. My knowledge of these serial ports and hex data  etc. is unfortunately very limited. 

Did you have any success getting this to work in Max? The device looks really promising, but wanted to check if you had any success getting it to behave in Max.

Quote: PaulvP wrote on Thu, 11 January 2007 03:55

----------------------------------------------------

> I'm using a Bluesentry bluetooth device with an accelerometer attached to it. I want to receive data from it in MaxMSP but it isnt working. With Hyperterminal it works fine, I get a string of Hex data. I have the [Llong] object to convert hex data to decimals, but it doesnt seem to help. The Bluesentry is acting as a Virtual COM port, and it seems to connect well with the [serial] object. The only thing is, I'm not getting any output. I use the [serial] help file to test this, the only thing I get printed are the numbers 63, 13 and 10.

Hi Paul (and others),
Did you have any success getting this to work in Max? The device looks really promising, but wanted to check if you had any success getting it to behave in Max.

Quote: PaulvP wrote on Thu, 11 January 2007 03:55
----------------------------------------------------
> Hi,
> I'm using a Bluesentry bluetooth device with an accelerometer attached to it. I want to receive data from it in MaxMSP but it isnt working. With Hyperterminal it works fine, I get a string of Hex data. I have the [Llong] object to convert hex data to decimals, but it doesnt seem to help. The Bluesentry is acting as a Virtual COM port, and it seems to connect well with the [serial] object. The only thing is, I'm not getting any output. I use the [serial] help file to test this, the only thing I get printed are the numbers 63, 13 and 10.
>
> Is there someone who has a solution?  
>
> Thanks in advance,
> Paul
----------------------------------------------------


I'm posting because i'm having problems working out with BlueSentry, any of you guys can help me out with it????

My problems are due to the data i'm receiving on pc, it's random and it's the same either i'm inputting a signal on BlueSentry or not..

it's really stopping me out in my project..:(

My problems are due to the data i'm receiving on pc, it's random and it's the same either i'm inputting a signal on BlueSentry or not..
Can anyone help me please???
it's really stopping me out in my project..:(

Bluesentry in MaxMsp