SparkFun will be closed Monday 7/4 for the holiday. All orders placed after 2pm MT on Friday 7/1 will be shipped out next week.

Member #435083

Member Since: May 4, 2013

Country: United States

  • Following the tutorial, which by the way now shows the default baud rate to be 115,200, I am able to use the following script to temporarily change the baud rate to 9600. But if instead I connect the BlueSmirf to the hardware Serial port and replace “bluetooth.command” with “Serial.command”, the baud rate stays at 115K. I have tried changing and adding delays, but no luck. Any ideas? I am trying to use the Bluesmirf to read a lot of data from a RocketRobot Android robot controller app and I think the amount of data might be overwhelming the SoftwareSerial.

    SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);

    void setup() { bluetooth.begin(115200); // The Bluetooth Mate defaults to 115200bps bluetooth.print(“$”); // Print three times individually bluetooth.print(“$”); bluetooth.print(“$”); // Enter command mode delay(100); // Short delay, wait for the Mate to send back CMD bluetooth.println(“U,9600,N”); // Temporarily Change the baudrate to 9600, no parity // 115200 can be too fast at times for NewSoftSerial to relay the data reliably bluetooth.begin(9600); // Start bluetooth serial at 9600 }

  • I am planning using this as a Xmas tree stand no-water alarm, although disabling the buzzer because I don’t feel the need to add water my tree at 2am. I was planning on re-programming the firmware to set off the alarm when there is no water versus the way it was designed to set off the alarm when there is water. I was pleasantly surprised that the current firmware works for both scenarios. It just depends on whether the sensor is already in water or not when the device first starts up and calibrates. Nice.

    How long can you make the sensor leads and not have a problem? The instructions say to keep them under 3 inches, but I probably need 6 inches to make it work for me. What problems will I run into if they are too long?

    Looking at the code and realizing that the ADC reading is about 1000 in air, under 600 in water and the alarm is set to go off with a difference over 100, why not just program it to alarm at 750 for no-water? Seems simpler because there is no initial calibration needed, but is not flexible in both water and no-water alarm modes if that was the intention.

    The comments in the code mention that you need to configure the ATtiny for 8Mhz so that so that serial and other parts of the code work correctly. What other parts besides SoftwareSerial wouldn’t work properly? Serial is not used by the Ohno device, but I assume this is in the firmware for troubleshooting if you can figure out how to get serial from the ATtiny. I assume if you are re-programming the chip you can choose 8Mhz off of the menu when programming.

    Just curious, how exactly does the sensor, internal pullup resistor circuit work to provide a different voltage the ADC can read when the sensor is in and out of water?

No public wish lists :(