Discussion Board

Results 1 to 2 of 2
  1. #1
    Registered User
    Join Date
    Oct 2004

    Exclamation Possible new Known Issue with the 6630


    Nokia Firmware: Nokia6630/3.45.110

    I'm having problems with reading from a Bluetooth Serial Port Profile connection, without the MIDlet crashing.

    I have to design a MIDlet capable of reading data from a Bluetooth device and display it in real-time. The device records 4 data channels at 250Hz (every 4ms), and sends them via Bluetooth.

    The device uses the Serial Port Profile, and the following settings: Baud Rate=9600, No Parity, 8 Data Bits, 1 Stop Bit, No Flow Control

    The code extends GameCanvas, and is running in it's own thread. Data is read from an InputStream. I've only been able to test this on a Nokia 6630.

    Setting the Thread.sleep() value to >=15ms gives reliable operation (still working after reading over 500KB)

    Setting the Thread.sleep() value to <15ms gives unreliable operation (works for typically 100 bytes to 15KB, but always crashes)

    while(true) {
      // for each pixel in the screen's width
      for(int k=0; k<=w; k++) {
        try {
          // wait until there's 37 bytes of data available
          while(last_res <37) {
            res = in.read(data, last_res, data_length-last_res);
            if (res == -1) {
              l1.severe("EOF found after " + count + " bytes");
             } else {
        } catch (IOException e) {
            l1.log(Level.SEVERE, "Read Error", e);
            // process data, and display on GameCanvas
       y_val = getHexValue(data, 4, 3);
            this_y1 = graphics_h - (int)(y_val / y_scale_factor);
       y_val = getHexValue(data, 13, 3);
       this_y2 = graphics_h - (int)(y_val / y_scale_factor);
       y_val = getHexValue(data, 22, 3);
       this_y3 = graphics_h - (int)(y_val / y_scale_factor);
       y_val = getHexValue(data, 31, 3);
       this_y4 = graphics_h - (int)(y_val / y_scale_factor);
       g.drawLine(k, 0, k, graphics_h);
       // channel 1
       g.drawLine(k-1, last_y1, k, this_y1);
       // channel 2
       g.drawLine(k-1, last_y2, k, this_y2);
       // channel 3
       g.drawLine(k-1, last_y3, k, this_y3);
       // channel 4
       g.drawLine(k-1, last_y4, k, this_y4);
       flushGraphics(k-1, 0, k, graphics_h);
       last_y1 = this_y1;
       last_y2 = this_y2;
       last_y3 = this_y3;
       last_y4 = this_y4;
          Thread.sleep(4); // 4ms per sample
       } catch (InterruptedException e) {}
    I've also tried the following Nokia code:

    int bytesRead = 0;
    while (bytesRead < buffer.length)
    int count = in.read(buffer,
    buffer.length - bytesRead);
    if (count == -1)
    throw new IOException("Input stream closed");
    bytesRead += count;
    And I get the same result.

    The interesting thing is that the number of bytes read without crashing is always a multiple of the byte[] size. i.e. in my first code, I would always be able to read in multiples of 37, then the phone would crash. This doesn't seem to be a coincidence. Further testing yielded the following results: (note all values are exactly divisible by 37)

    If the midlet is started first, and then the device starts sending data, the following amounts of data were read in before crashing, over 5 tests:

    1) 3959 bytes
    2) 4699 bytes
    3) 5661 bytes
    4) 6734 bytes
    5) 5661 bytes - phone restarted itself after this one!

    If the device starts sending first, then the midlet connects to it, the following amounts of data were read in before crashing, over 5 tests:

    1) 67192 bytes
    2) 71817 bytes
    3) 67192 bytes - phone restarted itself after this one!
    4) 66008 bytes
    5) 65046 bytes - phone restarted itself after this one!

    So it appears that starting to send data before connecting allows 10x more data to be read in and displayed. I believe this is because as soon as a StreamConnection is made to the device, data will be read in by the phone's bluetooth hardware and buffered for reading.

    By connecting to an already transmiting device, there will instantly be data available that can be buffered, thus allowing around 10x more data to be read before the hardware buffer is exhausted.

    Also, trying to do the following causes the phone to crash:

    try {
      int c= in.read();
      while (c != -1)
        c = in.read();
    } catch (IOException e) {
       log(Level.SEVERE, "IO Exception during read", e);
    It seems as though the read() method is either not blocking properly, or data is not being propagated through the phone correctly.

    Any help would be greatly appreciated.



  2. #2
    Registered User
    Join Date
    Apr 2004
    I've encountered a similar issue with v2 firmware on the 6630 -- data streamed too quickly from a client to the phone over an L2CAP connection will cause behavior as you described. I don't have exact numbers, but we had to insert even longer pauses to get it to work reliably.


Posting Permissions

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