But if she is the network, then this means she will not have access to NTP (Network Time Protocol), and the Raspberry Pi, which is her brain, doesn’t come with a real time clock(RTC). So I order an I2C connected Chronodot from Adafruit, and now Viobot has her own accurate RTC, and she no longer depends on NTP for time information.

Image from flickr user macetech

The actual wiring of the Chronodot to the Raspberry Pi was simple. I connected the GND and VCC pins to my 3.3V bus, and I connected the SDA and SCL pins from the Chronodot to the SDA(pin 3) and SCL(pin 5) pins on the Raspberry Pi GPIO header.

Getting this clock to work with the Raspberry Pi was pretty simple, but did take a big of digging around different sites for all the right information. So here I will present what I did to get the Chronodot to work with the Raspberry PI on Viobot.

Some background first: Viobot’s OS is the GNU/Linux variant from the Raspberry PI foundation called, “Raspbian wheezy”

My kernel and image are fully up to date, which is done by running the following as root:

apt-get update && apt-get dist-upgrade 
rpi-update

After the rpi-update command you have to reboot the Raspberry Pi, and we see the kernel is now version 3.2.27+

gregrob@rPI-a3d79a ~ $ uname -r
3.2.27+

Now I added some i2c packages

apt-get install i2c-tools libi2c-dev

By default the Raspberry Pi Raspbian config doesn’t load the I2C modules at boot. To change this we need to comment out or delete the I2C entry from the file: /etc/modprobe.d/raspi-blacklist.conf

And here we see I have commented out the I2C line:

root@rPI-a3d79a:/etc/modprobe.d# cat /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

blacklist spi-bcm2708
#blacklist i2c-bcm2708

In addition to the i2c-bcm2708 module we also want to specify some additional modules to load, and we do this by adding them to the file: /etc/modules

root@rPI-a3d79a:/etc# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

snd-bcm2835
8192cu
i2c-bcm2708
i2c-dev
rtc-ds1307

So the basic i2c module is loaded, the i2c-dev module is loaded, and finally the real time clock module is loaded. Here it appears we are loading the driver for only a ds1307 RTC module, but if you look into the source in the module you see the module now supports quite a few clock chips:

enum ds_type {
         ds_1307,
         ds_1337,
         ds_1338,
         ds_1339,
         ds_1340,
         ds_1388,
         ds_3231,
         m41t00,
         rx_8025,
         // rs5c372 too?  different address...
};

And the Chronodot is a DS3231, which is in the list.

The final step to get the RTC clock online is to let the i2c subsystem know it is out there on the bus. We do this by adding the following command to the /etc/rc.local file:

echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-0/new_device

We can now reboot, and after the system comes up I found my RTC had been set to the NTP automatically. Thus the RTC was now aware of the actual time, and going forward I could now shutdown NTP and set the system clock from the RTC at startup. So I removed the current fake hardware clock and NTP files from the init folders by using the following commands:

update-rc.d -f  fake-hwclock remove
update-rc.d -f  ntp remove

Then I added another line to rc.local to read the RTC time into the system time:

/sbin/hwclock -s

A final reboot, and the Raspberry Pi came up, and without NTP running the system clock was correct.

Here is the front bumper assembly with 4 IR proximity sensors:

So these sensors sit such that each pair is riding directly in front of the main robot running wheels. These are simple sensors that drive a line high if anything comes within 10cm of them. A single pair sits at the back of Viobot along her centre line. The sensors facing down detect that the ground is present, and the sensors facing outwards from Viobot detect if any object / wall / cat / etc… get too close. these all work fine, and charging full speed at a precipice the Arduino was able to stop the wheel motors in time to avert catastrophe.

So what is the problem? Well as also previously mentioned one of Viobot’s three means of sensing her environment is an IR distance sensor. This sensor is co-mounted with the webcam on a pan/tilt head and cam measure the distance to object out to 30cm away.

Since this sensor is also IR I expected there was a fair chance it would get interference from the proximity sensors, and it does. So, this was expected and I try a simple fix next, but a baffle between the proximity sensors and the ranging sensor, but no luck as expected.

At this point there are two approaches I could take, one is fairly simple which is to wire up the power feed to the front bumper such that it is controlled by an Arduino signal. A resistor and transistor should do the trick quite simply. But having read some of the info on the proximity sensors I know that they come with an “enable” connection which can be activated and wired out. In my mind the first is simpler to implement, but the second is more elegant. being the geek I am I went for the elegant solution.

This meant un-mounting all four front bumper IR sensors, cutting the trace that was holding the enable signal high, and soldering on new leads to a small pad on the bottom of the circuit board to bring the enable signal out to an Arduino pin. Once this was done I modified my Arduino sketch to enable the bumpers at start-up, and to disable them 40ms prior to taking a range reading from the ranging sensor.

The IR range sensor still didn’t work.

So it turns out the enable pin on the proximity sensors puts them into a low power mode, but does not appear to actually stop the IR transmitters. Thus the interference continues even when the sensors are disabled. So now I’ll have to go back and implement the control on the power feed to the front bumper, and all the time I spent on the “elegant” solution is wasted.

I have also uncovered a couple of power bugs that I need to trace down. 1) For some reason the 5V feed from the SSC-32 is actually producing 6 volts. 2) When the Raspberry PI is powered, but I have the 5V devices shut down at the battery, there is still 1.2 volts appearing on the 5V rail.

The SSC-32 is now buried pretty deep in Viobot’s guts. Where it is now I have access to the servor headers, but nothing else. I am not looking forward to pulling it out to figure out the 6V problem. And on the 1.2V problem I have already disconnected many leads that connect between the two halves of Viobot, but have not yet found where this power is flowing from.

Howto: So nothing has to be disconnected, but a lot of things have to be moved around to get at the SSC-32. 1) Drop the battery pack off the rear bumper to make room for -> 2) Rotate the Raspberry PI up on the hinged stand offs to clear the -> 3) Lift the pan/tilt assembly up an away from the top of the SSC-32 and finally -> 4) Access the SSC-32.

So to start with the bad news, Kodak annouced, in a cryptic manner, that they are planning to sell their film and paper business. http://www.kodak.com/ek/US/en/Kodak_Takes_Next_Steps_toward_Successful_Emergence.htm.
Now actually the press release was last week, but it takes some time to really appreciate what this may mean in the bigger scope of silver based photography. It is this week that their announcement has begun to strike me as something very bad. Kodak is currently in bankruptcy protection, and in case you don’t know, that means they are not bankrupt, but are re-organising in order to avoid becoming bankrupt. Many were hopeful that bankruptcy protection would have allowed them to restructure and right-size the film and paper business to match today’s actual market for such, which is very different than the market that their machinery and organisation was created to support. But instead they are throwing in the towel, and I can’t imagine anybody who would be looking to buy it.

The second bad news of the week, which struck me much harder than the Kodak announcement, as I do not actually shoot very much Kodak film any more, was that Efke is going to shut down their production of paper and film. Their coater has broken, and they do not think it is worth the investment to fix it based on their current revenue projections. Now you may say, I thought you mainly shoot Ilford, what does Efke have to do with anything? Well the thing is, I have shot Efke once to try it out, but that is not my interest; my interest is in New55 which is a project led by Bob Crowley to produce a modern replacement for Polaroid Type 55 positive/negative film, which was an excellent product for use in 4×5 cameras. It was like using any other Polaroid product in that you had an instant result, but it was like almost no other product in that the result was a beautiful 4×5 negative.

Efke 25 shot, developed in a monobath:

So how do Efke and New55 come together? Well the thing was in the planned New55 product the actual film inside the envelope was likely going to be Efke film. And if Efke is no longer going to be producing film then Bob is going to have to find some other source of film. It can’t just be any film, for what he is trying to do it needs to have certain characteristics that the Efke film has/had and that modern black & white films do not. Thus the death of Efke may be the death of New55.

But now we come to the positives, and the for the first, which I thought was just wonderful, we come back to New55; We are told by Bob on the New55 blog, that a handmade batch of New55 was produced and a few envelopes were sent out to some real world photographers. And here we have actual results that look wonderful of actual use of New55: (Warning link NSFW) http://www.zoewiseman.com/ZW/2012/09/02/new55-film/

New55 and Polaroid Type 55 positives side by side:

©2012 Zoe Wiseman

Reading Zoe’s blog this morning made me want to go out and shoot today, it showed me that all is not lost, and art with large format cameras is still here today with us. It also gave me hope that Bob is the right person to figure out how to get New55 off the ground despite the pitfalls currently occurring.

The other good news this week, and this is not as great as what is happening with New55, but is still pretty good; The Impossible Project announced the general availability of their 8×10 instant film solution. The price is quite high, and at first glance the quality still has a long way to go, but it was enough to show that things are moving in the right direction, and that despite the bad news this week, film is not yet dead. I even ended up ordering a box of 10 sheets, to be be shipped Sept 12th, and look forward to the adventure that should be.

FYI, here are a couple of old posts in which the image shown was shot using Polaroid Type 55:
http://gregrob.ca/blog/2009/07/on-flickr/
http://gregrob.ca/blog/2009/03/macro-test-image/

/* Viobot test sketch

Turns on and off a light emitting diode(LED)
Measures distance using IR sensor
Measure distance using ultrasonic sensor
Energise relay for wheel motors

*/

// constants won't change
int pingDPin = 4;
int relayDPin =3;
int ledDPin = 2;
int ir1APin = 0;

// Variables will change:
unsigned long currentMillis;
long previousMillisLED = 0; // will store last time LED was updated
long previousMillisPing = 0; // will store the last time the Ping was run
long previousMillisIR1 = 0; // will store the last time the IR1 sensor was run
long duration, pingcm;
float ir1voltage;
int ir1cm;

// the follow variables is a long because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long intervalLED = 500; // interval at which to blink (milliseconds)
long intervalPing = 2000; // interval at which to measer sonar distance
long intervalIR1 = 100; // interval at which to measure Sharp IR distance
int state = 0; // heartbeat LED state (previously scanned multiples LEDs)
// this array is an encoding of the Sharp GP2D120 IR Range Sensor voltage to distance as measured
// the key is 10 * the measured voltage
// valid values should be 4 thru 30cm
int sharpGP2D120[32] = {0, 0, 30, 27, 24, 17, 14, 11, 10, 9, 8, 8, 7, 7, 7, 6, 6, 5, 5, 4, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

void setup() {
// set the digital pin as output:
 pinMode(pingDPin, INPUT);
 pinMode(relayDPin, OUTPUT);
 digitalWrite(relayDPin, HIGH); // motors can run
 pinMode(ledDPin, OUTPUT);
 digitalWrite(ledDPin, LOW); // Arduino heartbeat LED off
 Serial.begin(115200);
}

void loop()
{
 currentMillis = millis(); // start of loop get the current time

 if(currentMillis - previousMillisLED > intervalLED) {
   // save the last time you blinked the LED
   previousMillisLED = currentMillis;
   state = state + 1;
   if(state == 3) {
     state = 1;
   }
   switch (state) {
     case 1:
       digitalWrite(ledDPin, LOW);
       break;
     case 2:
       digitalWrite(ledDPin, HIGH);
       break;
   }
 } // end of if blink LEDs, the LED code is more complex than necessary as it previously did a lot more
 // and may again do more in the future
 currentMillis = millis();

 if(currentMillis - previousMillisPing > intervalPing) {
   // save the last time you measured the distance
   previousMillisPing = currentMillis;
   pinMode(pingDPin, OUTPUT); // send a short high pulse to the sensor to tell it to begin a measurement cycle
   digitalWrite(pingDPin, LOW);
   delayMicroseconds(2); // these are very short delays
   digitalWrite(pingDPin, HIGH);
   delayMicroseconds(5);
   digitalWrite(pingDPin, LOW);
   pinMode(pingDPin, INPUT);
   duration = pulseIn(pingDPin, HIGH, 17400); // timeout = 3 m * 100 cm/m * 29 ms/cm * 2(roundtrip)
   if(duration != 0) {
     pingcm = (duration / 29 / 2) + 1; // 29 microseconds per cm, divide by 2 for round trip, plus 1 cm fudge factor
     Serial.print("Ping: ");
     Serial.print(pingcm);
     Serial.println(" cm");
   }
 } // End of if PING
 currentMillis = millis();

 if(currentMillis - previousMillisIR1 > intervalIR1) {
   // save the last time you measured the distance
   previousMillisIR1 = currentMillis;
   ir1voltage = analogRead(ir1APin) / 1024.0 * 3.0; // (measured_voltage / steps * max_output_voltage)
   if(ir1voltage>0.25) {
     ir1cm = sharpGP2D120[int(ir1voltage*10+0.5)];
     if(ir1cm > 0) {
       Serial.print("IR1: ");
       Serial.print(ir1cm);
       Serial.println(" cm");
     }
   }
 } // End of if IR1
} // End of sketch

As far as physical connections, still to come are: 1) IR sensors for front bumpers. 2) A 6000 mAh LiPo battery and charging system to run the Raspberry Pi, I expect it to come in the mail on Monday. 3) I still haven’t found a USB WiFi adapter that works well with a Raspberry Pi. I have ordered a couple of old b/g adapters online but do not know when one may arrive.

The next step is software integration, and more about that will come in a subsequent post. For now some details on the system integration.

I decided that instead of trying to get the sensors to work with the Raspberry Pi, that I would instead hook them up to an Arduino Nano. This eliminates all of the headaches of trying to get realtime sensors that need precise timing to work with a non-realtime operating system. In addition I decided that the Arduino should be capable of stopping Viobot from crashing into objects. So the Arduino controls a relay which in turn controls the power flow to the wheel motors. Thus in case of impending doom the Arduino will first try and tell the Raspberry PI to stop the motion, but if the Raspberry Pi doesn’t react in time the Arduino will cut the power to the wheels. At the same time power to the motors in the sensor pan/tilt heads will remain on.

So integration: Part 1, Power
The lower level of Viobot consists of the Lynxmotion SSC-32 Servo motor controller, the Arduino Nano, and a relay board. These are all running off of 5V. The supply for this power comes from 4xAA batteries mounted under Viobot’s deck. The 6V from the AAs is fed to a power switch and then splits 3 ways: 1) Direct to the SSC-32 Logic input, which feeds a 5V regulator on the SSC-32 and from there all of the logic chips on board. 2) Direct to to 1/2 of the motor power inputs on the SSC-32. This feeds the motors on the pan/tilt heads. 3) To the relay controlled by the Arduino. Then from the normally open terminal of the relay to the second 1/2 of the motor power inputs on the SSC-32. This feeds Viobot’s wheel motors.

The 5V regulated supply on the SSC-32 is available on some header pins in the middle of the board, and from here some jumpers feed 5V into the Arduino Nano, and also feeds the 5V supply required by the relay board. This ground at this point also connects to the upper level of Viobot.

On the top level of Viobot we are dealing with 5V supply, but with a 3.3V logic levels. The 5V is brought in through a USB hub which is acting both as a hub for the Raspberry Pi, and also the power supply for the Raspberry Pi. I hacked a $9.99 hub that I had picked up from Canada Computers. So that it could take in external power, without taking power out of the PI USB port. One of the leads feeds the Micro-B power supply connector on the Pi, and another lead was lenghted, and the power cut to feed serial communications to the Arduino Nano. The following illustrates the idea:

I have not tested this under full load yet.

Part 2, Logic
The second part of the integration was to wire all the separate components signals together. The Arduino Nano is sitting on a small breadboard so this was plug-and-play action. I also have a small breadboard power strip on the lower level for 5V power. Another small power strip on the top level provides connections for 3.3V power. I have a cut out in the plexi-glass above the Raspberry Pi that allows easy access to the GPIO pins and plugged jumper wires directly onto them.

The signal connection from the Raspberry Pi to the Arduino is USB, and was completed by simply plugging in the lengthened Mini-B connected from the USB hub into the Nano. There is no power on this lead as the 5V devices are running from the AA batteries. This connection appears as /dev/ttyUSB0 on the pi, and as the primary hardware serial port in the nano. The USB link is used to program the Nano from the Pi using command line Makefile from Martin’s Atelier. This same USB link is then later used for the nano to communicate sensor data back to the pi.

The signal connection from the Raspberry Pi to the Lynxmotion SSC-32 is TTL serial, but the pi is 3.3V and the SSC-32 is 5V, so a level converter had to be used. So the TxD and RxD pins on the GPIO are connected to low voltage side of the converter, and then from the high voltage side we connect to the RxD and TxD pins on the SSC-32. This connection appears as /dev/AMA0 on the pi.

The sensors connect very easily to the Nano. The Sharp IR sensor connects to an analog pin, and produces a voltage from 0 to 3 volts representing the distance measured by the sensor. The Parallax Ping))) is connected to a digital pin, and the length of the pulse received is equal to the time is took for the sound waves to travel from the transmitter to the target and back to the receiver. The relay is connected to a digital pin which at this point is energised as long as the nano is running. There is also a hearbeat LED on another digital pin so that I know my sketch is operating.

At the end of the day today I have used minicom on the Pi to observe sensor readings coming from the nano on /dev/ttyUSB0, and also used it to send motor commands to the SSC-32 on /dev/ttyAMA0.

So the base assembly here is going to be a Boe-bot two-wheel chassis and motors. The Boe-Bot I purchased is the parts only kit. It doesn’t come in the retail box, it doesn’t include the 300 page manual/textbook, it doesn’t include the Boe-Board, it doesn’t have a USB interface. It does cost only half the price of the full Boe-Bot kit, and what I plan to stack on top is a few orders of magnitude more powerful than the standard kit.

Instead of the Boe-Board I am using two different components. To drive the servo-motors I purchased a Lynxmotion SSC-32 servo motor controller. This is a really dynamic board with a TTL serial interface that can be used for simple commands, or with complex stored sequencing. The SSC-32 is a significant upgrade from the 4 simple servo ports in the standard kit. This board may have a future in a walking robot but that will not be soon as I cannot afford that many servos.

The second component replacing functions on the Boe-Board is the brains, in this case a Raspberry PI GNU/Linux computer. This is a full fledged computer, which gives us a ton of flexibility in development, and taps into the enormous reservoir of pre-exisiting applications and source code. Again a significant upgrade from the Basic stamp used for brains in the standard kit.

Here are a few pics of the project so far. At this point we have a fancy remote-control car driven over bluetooth from my desktop PC.

Robot Parts (click on the picture to go to flickr if you want to see more detail and notes)

Robot Brains

Assembled Chassis

I think I will re-do the mount for the SSC-32. I need to drill some more holes in the deck of the Boe-bot, and then flip the whole SSC assembly over. The next step after that will be to figure out how to mount the Raspberry PI, I’ll be hand cutting some Lexan parts for that.

As part of the brainstorming on things I may want to do with my Raspberry PI, one thing that had occurred to me (and many others) would be to inter-work it with an Arduino. Now, this could be done via a USB cable, but I like to explore, and so instead I looked into a Bluetooth connection. I found on the Robotshop site a nice little module from DFRobot for $24 that could connect directly to the TTL serial port on an Arduino.

http://www.robotshop.com/ca/productinfo.aspx?pc=RB-Dfr-10&lang=en-US

But once I had this in hand, the question was how I am going to program it, set the baud rate etc? I comes set at 9600, and I wanted to turn it up to 38400. Since it uses TTL serial instead of RS-232 levels I could not directly connect it to a normal computer unless I used a level shifter. I didn’t at the time have a level shifter. My solution was to use the Arduino to act as an interface between the USB port on my computer and the TTL serial interface on the BluetoothV3.

I put a simple sketch onto the Arduino to connect the BluetoothV3 via a softserial port on pins D9 and D10. I then used the serial monitor that comes installed in the Arduino package to talk thru the Arduino the the Bluetooth device.

Notes:
1) In the serial monitor set it so that you are sending CR/LF terminations or else you won’t ever get a response from the BluetoothV3
2) On the BluetoothV3 you need to set the AT DIP switch to, “on” to indicate that the device should look for AT commands. Slide it back to off once you have completed your programming.
3) The BluetoothV3 does not remember pairing during a power cycle. Thus when communicating via bluetooth with other devices you may have to delete and re-pair the V3 after start-up. For example from an Android tablet, the tablet believed it was still paired with the V3, but would return a “Connect failed” error when trying to connect to the V3; but if I deleted the V3 from the Android’s known devices list it would then pair and connect without issue.

References:
1) This document lists the AT commands that the BluetoothV3 accepts: http://www.dfrobot.com/image/data/TEL0026/TEL0026_Datasheet.pdf

Here is the sketch that I ran on the Arduino. Change the baud rate in procedure, “setupBlueToothConnection” to 9600 for when you first start with the programming. Change it to 38400 after you have sent an, “AT+ORGL” command. Or set it the whatever speed you have set using an, “AT+UART” command.

/*
Based on example code from others

Uses softserial on D9 (RxD),D10 (TxD) to talk to bluetooth modem
*/

#include <SoftwareSerial.h> //Software Serial Port
#define RxD 9
#define TxD 10
SoftwareSerial blueToothSerial(RxD,TxD);
char incoming;
void setup()
{
  Serial.begin(9600);
  delay(1000);
  pinMode(RxD, INPUT);
  pinMode(TxD, OUTPUT);
  setupBlueToothConnection();
  Serial.println("Started");
}
void setupBlueToothConnection()
{
  blueToothSerial.begin(38400); //Set BluetoothV3 baud rate to 38400
  delay(1000);
}

void loop()
{
  if (blueToothSerial.available())
    Serial.write(blueToothSerial.read());
  if (Serial.available())
    blueToothSerial.write(Serial.read());
}

So the simple drawing:

PC –ethernet–> RaspberryPI –USB–> BluetoothDongle –wireless–> BlutoothModem –TTLserial–> ArduinoNano –> shiny lights

———————————————————————————

And some pictures since this sometimes is a photo blog:
\
The PC, basically a terminal

The Raspberry PI GNU/Linux computer with USB Bluetooth dongle

The Arduino Nano and the Bluetooth modem/serial adapter

ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKSEN.
IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

——————————————————–

So getting the Raspberry PI to pair and then communicate with the DF Robots Bluetooth modem took a lot longer than I expected. In the end the problem was that I need to use the appplication, “bluetooth-agent” to provide the PIN to pair the devices. This was not clear as most online references for bluez refer to either using the GUI, or using “/etc/bluetooth/hcid.conf”. But I eventually found some info that said hcid.conf was no longer part of bluez, and that for command line pairing you could use bluetooth-agent.

For all of this example I am running linux image: 2012-07-15-wheezy-raspbian

A short summary of commands, all of these are run as root or using sudo:
1) To install bluez and minicom

apt-get install bluez minicom

2) Make sure bluetooth services are running

/etc/init.d/bluetooth start

3) Clean up before we start

rfcomm release hci0
hciconfig -a hci0 reset

4) Check that your bluetooth device is working (third line of response says UP)

hciconfig -a
 hci0: Type: BR/EDR Bus: USB
 BD Address: 00:15:83:3D:0A:57 ACL MTU: 192:8 SCO MTU: 64:8
 UP RUNNING PSCAN
 RX bytes:12234 acl:112 sco:0 events:427 errors:0
 TX bytes:3253 acl:78 sco:0 commands:177 errors:0
 ...
 

5) Find the address for the far-end bluetooth modem (address is XX:XX:XX:XX:XX:XX in response)

hcitool scan
 Scanning ...
 00:12:04:20:50:55 H-C-2010-06-01

6) Optionall try pinging to see if we can talk to the far device

l2ping 00:12:04:20:50:55 
 Ping: 00:12:04:20:50:55 from 00:15:83:3D:0A:57 (data size 44) ...
 4 bytes from 00:12:04:20:50:55 id 0 time 13.51ms
 4 bytes from 00:12:04:20:50:55 id 1 time 75.69ms
 4 bytes from 00:12:04:20:50:55 id 2 time 36.93ms

7) Find the channel used for SP (serial protocol) on the far-end bluetooth modem (channel info in protocol descriptor section)

sdptool search SP 00:12:04:20:50:55
 Inquiring ...
 Searching for SP on 00:12:04:20:50:55 ...
 Service Name: Dev B
 Service RecHandle: 0x10000
 Service Class ID List:
   "Serial Port" (0x1101)
 Protocol Descriptor List:
   "L2CAP" (0x0100)
   "RFCOMM" (0x0003)
     Channel: 1
 Language Base Attr List:
   code_ISO639: 0x656e
   encoding:    0x6a
   base_offset: 0x100

8. Start (and leave running) the bluetooth agent to send the PIN to the far end when it is asked for. In this case my PIN is 1234.

bluetooth-agent 1234 hci0 &

9) Start the connection from /dev/rfcomm0 device to the far end. Here we use our address and channel “00:12:04:20:50:55 1″

sudo rfcomm connect hci0  00:12:04:20:50:55 1

11) Now in another window, as a regular user, we can use minicom to connect over the link. In this case I am using 38,400 bps as this is what is in my Arduino sketch and what is set in the DF Robot BluetoothV3.

sudo minicom -D /dev/rfcomm0 -b 38400

-or to run minicom without using sudo-

sudo ln /dev/rfcomm0 /dev/ttyS0
sudo chmod 766 /dev/ttyS0
minicom -D /dev/ttyS0 -b 38400

——————————————————————————
Wow, that was a lot of crap.
But how did you initially setup the DFRobot BluetoothV3?
What sketch is running on the Arduino?

I’ll do that in another post. It is getting late.