​ ​ ​ ​ Picaxe + AppInventor Orientation Sensor - Page 2
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 11 to 20 of 32

Thread: Picaxe + AppInventor Orientation Sensor

  1. #11
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    128
    Blog Entries
    1

    Default

    so when will the byte(s) in the buffer get overwritten, when the third byte arrives?

  2. #12
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,373

    Default

    No bytes get overwritten AFAIR; any after the second will be lost.

    You can set up a test program which sends one, two or more bytes out and back into the HSERIN pin, then read what you get back.

    Something like this though you cannot use both HSEROUT and SERTXD on an 08M2 -

    Code:
    #Picaxe 18M2
    #Terminal 4800
    HSerSetup B4800_4, %000
    Do
      HserOut 0, ("ABCD")
      Pause 1000
      Do 
        w0 = -1
        HSerIn w0
        If b1 = 0 Then
          SerTxd( b0, CR, LF )
        End If
     Loop Until b1 <> 0
     SerTxd( "<Empty>", CR, LF )
    Loop

  3. #13
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    128
    Blog Entries
    1

    Default

    Just out of curiosity, is the -1 just used as an invalid value, or is there significance to the negative value? Am I correct in thinking this has to do with 2's complement?

  4. #14
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    476

    Default

    Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?

    Or am I wrong? (It's been known )

  5. #15
    Senior Member
    Join Date
    Jan 2010
    Location
    34 France
    Posts
    3,919

    Default

    Quote Originally Posted by PhilHornby View Post
    Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?

    Or am I wrong? (It's been known )
    I think so
    For Picaxe (with serin), in AppInvent, I use:

    Code:
    call BluetoothClient1.SendBytes
    list make a list get xx
    get yy
    S'il n'y a pas de solution, c'est qu'il n'y a pas de problème . (Les Shadoks)

  6. #16
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,373

    Default

    Quote Originally Posted by JSDL View Post
    Just out of curiosity, is the -1 just used as an invalid value, or is there significance to the negative value? Am I correct in thinking this has to do with 2's complement?
    It's just a convenient trick for putting a non-zero value into the MSB of the variable HSERIN reads into. When a byte is read the MSB is zeroed, if not the MSB remains non-zero.

  7. #17
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,373

    Default

    Quote Originally Posted by PhilHornby View Post
    Have you taken on-board, my point in Post #8 - that the data from the Android app., via the HC-06 is not two binary bytes - it's an ASCII string of characters?
    That is my understanding too. It sends the data as one long text string. The original code uses something like -

    Bluetooth1.Send.Text = Join( pitch + "," + roll + "<CR>" )

    I would expect that to send out a single string as multiple ASCII characters, for example -

    "-2518,7834<CR>"

    In traditional Basic parlance, the number would be auto-converted to a string using STR$() rather than CHR$().

    That's why the first step is to check what the HC-06 is actually outputting. Though similar could be achieved by sending via Bluettoth and putting that data in a label box in the AI2 app -

    var = Join( pitch + "," + roll + "<CR>" )
    Bluetooth1.Send.Text = var
    Label1.Text = var

    If it is sending a string of ASCII as above, that can be read with -

    SERIN PIN, BAUD, #pitch, #roll

    But as noted messes with SERVO because SERIN is blocking. The same cannot be read using two consecutive HSERIN.

    There is also an issue that any minus signs would be ignored. The string would need to have a plus forced if non-negative, then read with -

    SERIN PIN, BAUD, pitchSign, #pitch, rollSign, #roll

    There may be a way to send two binary bytes using AI2 but we don't know what AI2 code is being used.

    I like the suggestion earlier of using two PICAXE devices. The first using SERIN to read the Bluetooth data and sending two binary bytes to the second. The second using HSERIN to read those two bytes and controlling the servo. That would also allow a timed servo loop rather than SERVO/SERVOPOS which will remove any jitter there may be.

  8. #18
    Senior Member
    Join Date
    Jun 2014
    Location
    Canada
    Posts
    128
    Blog Entries
    1

    Default

    problem solved, I ended up using a 28X2 with background receive and a qualifier. The data fell into the appropriate variables spot on consistently. I like the idea of the two chip setup and thought of that as well, but I wanted to exhaust every

    possibility (which I think I did), to get it working with a single chip. Background receive on the X2 saved the day! All is working well now and the servo moves to the desired position accordingly. I simply could not get consistent results with

    the M2 chips using Hserin. The data was received, but would get out of sync quite often due to timing issues, therefore messing up the servo movements. One more question, the servo moves are quite fast, is the only way to slow them down

    to step to the servo position using a FOR...NEXT loop with a PAUSE in between, or is there a better way? The Arduino has a varspeedservo library with a slowmove procedure, but I think that's essentially what it is doing. Thanks for everyone's

    help.

  9. #19
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    476

    Question

    Quote Originally Posted by JSDL View Post
    problem solved, I ended up using a 28X2 with background receive and a qualifier. The data fell into the appropriate variables spot on consistently... Background receive on the X2 saved the day! All is working well now and the servo moves to the desired position accordingly.
    If you have modified the Android App ('Imagineering_maze.apk'), then I could understand what you are saying...

    However, in its current form, as downloaded from the 'instructable' web site, this just can't be right

    I loaded the app. onto my Huawei P9 and paired the phone with a HC-05 in slave mode. The HC-05 was connected to a (fake) FTDI-232R and plugged into my Windows 10 PC. On the PC, I used Realterm to dump the data that the phone sends.

    The app. sends ASCII data like this :-
    Code:
    10,0<lf>
    10,-1<lf>
    10,-1<lf>
    10,-1<lf>
    12,-1<lf>
    14,0<lf>
    15,0<lf>
    15,0<lf>
    14,-1<lf>
    
    At rest, on a flat surface, my phone sends the following ASCII string, repeatedly: "0,0<lf>", i.e. it is sending four binary bytes -> 30,2C,30,0A

    Each parameter appears to have minimum value of -30 and a maximum value of +30, depending on the phone's orientation. (I don't know if this is Phone or Android Version specific - mine's V7.0).

    There is no appropriate qualifier to wait for - only a terminator. Hserin does not perform ASCII to binary conversion, so whatever values you have received, they're misinterpreted chunks of ASCII data, not the actual values of the parameters being sent. (For starters, Picaxe Basic doesn't support signed numbers).

    Quote Originally Posted by The Manual
    Users familiar with the serin command will note the hserin command has a completely different format. This is because the hserin command supports much higher baud rates than serin, and so is unable to process received bytes ’on the fly’ (e.g. by changing ASCII into binary, as with the serin # prefix), as there is insufficient time for this processing to occur before the next hserin byte is received (at high baud rates). Therefore the raw data is simply saved in the memory and the user program must then process the raw data when all the bytes have been received.
    One interesting issue I had, is that my HC-05 was only running at 9600baud. This introduced a 3 second lag every time I moved the phone, while it emptied its buffer.

    UPDATED
    Just to add - the 'instructable' implies that the values sent are the actual angles that the phone is being held at - and that they should be constrained to ±15 (by the receiver). On my phone, they don't correspond to the actual angle of the phone (unless the Android app. is also constraining them, but to ±30 instead)
    Last edited by PhilHornby; 23-12-2017 at 02:08. Reason: Bit more info.

  10. #20
    Senior Member
    Join Date
    Jan 2010
    Location
    34 France
    Posts
    3,919

    Default

    Quote Originally Posted by PhilHornby View Post

    At rest, on a flat surface, my phone sends the following ASCII string, repeatedly: "0,0<lf>", i.e. it is sending four binary bytes -> 30,2C,30,0A

    Each parameter appears to have minimum value of -30 and a maximum value of +30, depending on the phone's orientation. (I don't know if this is Phone or Android Version specific - mine's V7.0).


    UPDATED
    Just to add - the 'instructable' implies that the values sent are the actual angles that the phone is being held at - and that they should be constrained to ±15 (by the receiver). On my phone, they don't correspond to the actual angle of the phone (unless the Android app. is also constraining them, but to ±30 instead)
    Hi,
    Phone orientation sensor is -90 , +90, but this Androïd appli give OrientationSensor1.Pitch /3 and OrientationSensor1.Roll /3
    to avoid negative value, its better to add 100 and use call BluetoothClient1.SendByte list make a list get....
    S'il n'y a pas de solution, c'est qu'il n'y a pas de problème . (Les Shadoks)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •