Forums > MaxMSP

Bluesentry in MaxMsp


PT
January 11, 2007 | 10:55 am

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


January 11, 2007 | 11:11 am

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".

jb

Am 11.01.2007 um 11:55 schrieb Paul:

>
> 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:

‘ {$STAMP BS2}
‘ {$PBASIC 2.5}

‘ 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

(Listing 1: Using the DEC formatter)

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

‘ {$STAMP BS2}
‘ {$PBASIC 2.5}

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

myVar VAR WORD

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

(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 (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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 141 53 67 196617 49 48 50 52;
#P newex 105 191 64 196617 fromsymbol;
#P newex 105 162 40 196617 itoa;
#P number 105 304 50 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 82 82 211 196617 t b l l b;
#P message 283 222 33 196617 set 0;
#P newex 105 276 40 196617 accum;
#P newex 105 136 27 196617 t i b;
#P newex 105 113 25 196617 iter;
#P newex 105 222 51 196617 *;
#P newex 178 190 97 196617 expr pow(10\,$i1);
#P newex 208 138 27 196617 – 1;
#N counter 1 1 0;
#X flags 0 0;
#P newobj 178 162 71 196617 counter 1 1 0;
#P message 82 53 52 196617 50 53 54;
#P newex 208 113 34 196617 zl len;
#P connect 14 0 10 0;
#P connect 5 0 8 1;
#P connect 13 0 5 0;
#P connect 12 0 13 0;
#P connect 7 0 12 0;
#P fasten 4 0 5 1 183 217 151 217;
#P connect 8 0 11 0;
#P connect 1 0 10 0;
#P fasten 10 0 8 0 87 269 110 269;
#P fasten 10 1 6 0 154 106 110 106;
#P fasten 10 2 0 0 221 106 213 106;
#P connect 10 3 9 0;
#P fasten 9 0 8 0 288 267 110 267;
#P fasten 7 1 2 0 127 156 183 156;
#P connect 6 0 7 0;
#P connect 2 0 4 0;
#P connect 3 0 2 2;
#P connect 0 0 3 0;
#P window clipboard copycount 15;

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: 0×0201. HIGHBYTE is 0×02, or 2 decimal.
LOWBYTE is 0×01, 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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 140 78 49 196617 255 254;
#P message 112 78 23 196617 2 1;
#P newex 112 103 58 196617 unpack 0 0;
#P number 112 201 60 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 112 169 58 196617 +;
#P newex 112 133 29 196617 < < 8;
#P connect 5 0 3 0;
#P connect 3 1 1 1;
#P fasten 3 0 0 0 117 126 117 126;
#P connect 4 0 3 0;
#P connect 1 0 2 0;
#P connect 0 0 1 0;
#P window clipboard copycount 6;

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.

‘ {$STAMP BS2}
‘ {$PBASIC 2.5}

myVar VAR WORD
mySeparator VAR WORD

‘ set mySeparator to 0xFFFF
mySeparator = 65535

Main:
FOR myVar = 0 TO 1024

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

(Listing 3: using separator variable)

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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P user com 410 353 281 196617 21;
#K set 0 16672 12853 13600 26990 8308 26725 8268 20311 16985 21573
8304 29285 29541 28276 29472 28271 8304 29295 25196 25965 29486;
#K end;
#P window linecount 3;
#P user com 459 384 281 196617 61;
#K set 0 22373 8300 26989 26996 8308 26725 8306 24942 26469 8303
26144 26990 25455 28009 28263 8292 24948 24864 29807 8293 30819 27765
25701 8308 26725 8242 13622 8302 30061 25189 29299 8311 26996 26656
18505 18248 16985 21573 8240 30790 17952 10290 13621 10542 8276 26725
29541 8289 29285 8292 25955 26989 24940 8246 13618 14384 8237 8246
13621 13109 11776;
#K end;
#P window linecount 4;
#P user com 302 130 281 196617 97;
#K set 0 21608 25888 26990 29797 28260 25956 8310 24940 30053 8240
30790 17968 12320 10290 13621 11296 12329 8311 26729 25448 8291 28525
25971 8289 26228 25970 8308 26725 8307 25968 24946 24948 28530 8291
24942 28271 29728 25189 8306 25953 25644 8290 25955 24949 29541 8297
29735 29472 26990 29797 29296 29285 29797 25632 24947 8289 28271
29800 25970 8307 25968 24946 24948 28530 11296 30569 29800 8308 26725
8304 29285 30313 28533 29472 25209 29797 11808 21608 26995 8291 24949
29541 29472 24942 8309 28265 28276 25966 25701 25632 28518 26227
25972 11808 21359 11822 11776;
#K end;
#P window linecount 1;
#P newex 743 325 21 196617 t 0;
#P button 368 285 15 0;
#P newex 296 621 74 196617 print gooddata;
#P newex 296 442 21 196617 t 1;
#P newex 296 481 29 196617 gate;
#P message 368 478 70 196617 mode group 2;
#P newex 296 518 55 196617 zl group 2;
#P newex 368 439 32 196617 sel 1;
#P newex 368 416 54 196617 &&;
#P newex 368 391 43 196617 == 255;
#P newex 412 391 43 196617 == 255;
#P newex 368 368 48 196617 bucket 2;
#P window linecount 2;
#P message 368 326 247 196617 255 , 255 , 253 , 0 , 254 , 1 , 0
, 1 , 1 , 1 , 2 , 1 , 3 , 1 , 4 , 1 , 5 , 1 , 0 , 255 ,
255 , 255 , 0 , 1 , 0 , 2 , 0 , 3 , 0 , 4;
#P window linecount 1;
#P newex 296 544 58 196617 unpack 0 0;
#P newex 296 594 58 196617 +;
#P newex 296 568 29 196617 < < 8;
#P user com 388 292 433 196617 41;
#K set 0 25189 29812 25970 8292 24948 24890 8290 31008 28526 27769
8309 29545 28263 8310 24940 30053 29472 12408 12336 12336 8237 8240
30790 17712 12332 8289 28192 26990 25455 28009 28263 8242 13621 8297
29472 30062 24941 25193 26485 28533 29440;
#K end;
#P newex 585 79 21 196617 t 0;
#P button 210 39 15 0;
#P newex 138 369 69 196617 print baddata;
#P newex 138 190 21 196617 t 1;
#P newex 138 229 29 196617 gate;
#P message 210 226 70 196617 mode group 2;
#P newex 138 266 55 196617 zl group 2;
#P newex 210 187 32 196617 sel 1;
#P newex 210 164 54 196617 &&;
#P newex 210 139 43 196617 == 255;
#P newex 254 139 43 196617 == 255;
#P newex 210 106 48 196617 bucket 2;
#P message 210 80 363 196617 1 , 0 , 1 , 1 , 1 , 2 , 255 , 255
, 255 , 0 , 254 , 1 , 0 , 1 , 1 , 1 , 2 , 1 , 3 , 1 , 4
, 1 , 5 , 1;
#P newex 138 292 58 196617 unpack 0 0;
#P newex 138 342 58 196617 +;
#P newex 138 316 29 196617 < < 8;
#P window linecount 2;
#P comment 281 227 115 196617 resets the grouping to insure correct
order;
#P window linecount 3;
#P comment 14 193 121 196617 open gate when first pair of 255s comes
through ; previous input ignored;
#P comment 610 73 100 196617 close the gate until a separator WORD
comes through;
#P window linecount 1;
#P comment 224 66 319 196617 problematic data set: we CANNOT use
values with HIGHBYTE 255;
#P window linecount 2;
#P comment 302 104 281 196617 THIS EXAMPLE DEMONSTRATES A LIMITATION
OF USING A SEPARATOR – CERTAIN VALUES CANNOT BE USED AS DATA.;
#P fasten 25 0 33 1 373 359 320 359;
#P connect 25 0 26 0;
#P connect 5 0 6 0;
#P fasten 7 0 5 0 143 315 143 315;
#P connect 7 1 6 1;
#P connect 9 0 11 0;
#P connect 9 1 10 0;
#P connect 11 0 12 0;
#P connect 10 0 12 1;
#P connect 12 0 13 0;
#P connect 15 0 14 0;
#P connect 16 0 14 0;
#P connect 17 0 16 0;
#P connect 14 0 7 0;
#P fasten 20 0 16 0 590 221 143 221;
#P fasten 19 0 20 0 215 62 590 62;
#P connect 19 0 8 0;
#P connect 8 0 9 0;
#P fasten 8 0 16 1 215 99 162 99;
#P connect 13 0 15 0;
#P fasten 13 0 17 0 215 211 193 211 193 183 143 183;
#P connect 6 0 18 0;
#P fasten 37 0 33 0 748 467 301 467;
#P connect 31 0 24 0;
#P connect 34 0 33 0;
#P connect 33 0 31 0;
#P connect 32 0 31 0;
#P connect 29 0 30 0;
#P connect 27 0 29 1;
#P connect 28 0 29 0;
#P connect 26 1 27 0;
#P connect 26 0 28 0;
#P connect 24 1 23 1;
#P fasten 24 0 22 0 301 567 301 567;
#P connect 22 0 23 0;
#P connect 23 0 35 0;
#P connect 30 0 32 0;
#P fasten 30 0 34 0 373 463 351 463 351 435 301 435;
#P fasten 36 0 37 0 373 308 748 308;
#P connect 36 0 25 0;
#P window clipboard copycount 41;

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.



PT
January 11, 2007 | 3:33 pm

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.

paul


March 29, 2007 | 6:49 pm

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.

Thanks,
David

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
—————————————————-


November 11, 2008 | 9:40 am

Hi there!

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..
Can anyone help me please???
it’s really stopping me out in my project..:(

Thanks

Regards,
Rui Lopes


Viewing 5 posts - 1 through 5 (of 5 total)