gerta

Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • in reply to: TinyG initialization #12139
    gerta
    Participant

    Digging into my CoolTerm and TinyG settings, I noticed RTS/CTS flow control was enabled. Disabling flow control on the TinyG by setting $ex=0 solved the problem: I can now power cycle the TinyG and freely communicate with the Pico over serial.

    I don’t see RTS or CTS contacts on the board, but I assume they must be connected somewhere if I’m able to use flow control over USB. Is there any way to solder on RTS/CTS pins, or am I out of luck apart from the USB port?

    in reply to: TinyG initialization #12138
    gerta
    Participant

    To add some additional detail, I find that in order to get serial communication working, I need to establish a connection with the TinyG over USB using CoolTerm. Serial communication with the Pico works fine, even if I unplug the USB cable from the TinyG. However, if I close the CoolTerm connection, serial communication with the Pico instantly halts, even if the USB cable is still connected. This behavior reinforces my interpretation that there’s some sort of communications sign-on and sign-off being through my CoolTerm connection that I’m missing on the Pico serial connection.

    in reply to: Arduino Serial Control of TinyG #12129
    gerta
    Participant

    A quick note to follow up in case anyone else tries this. I got things partly working using the AltSoftSerial library, but the replies from the TinyG were somewhat garbled, much as shown in the initial post of this thread. Fiddling with the program and checking around online, I discovered the standard TinyG baud rate of 115200 is just way too high for SoftwareSerial and a little too high to be dependable in the case of AltSoftSerial. Serial Tx from Arduino to TinyG does work at 115200, or at least enough to send an initial command to dial back the speed. Setting all communication to 9600 baud gives expected behavior.

    Functional, minimal code below works either through SoftwareSerial (as-is) or AltSoftSerial (comment out first 2 lines, uncomment subsequent 2 lines):

    #include <SoftwareSerial.h>
    SoftwareSerial tinyGSerial(8,9);
    //#include <AltSoftSerial.h>
    //AltSoftSerial tinyGSerial;
    
    byte ctrlX = 0x18; // TinyG reset command
    char myChar;
    
    void setup() {
      Serial.begin(9600);
      tinyGSerial.begin(115200);
      delay(1000);
    
      tinyGSerial.println("$baud=1");
      tinyGSerial.end();
      tinyGSerial.flush();
      delay(1000);
      tinyGSerial.begin(9600);
      delay(1000);
    }
    
    void loop() {
      if (Serial.available()) {
        myChar=Serial.read();
        tinyGSerial.print(myChar);
      }
      while (tinyGSerial.available()) {
        myChar=tinyGSerial.read();
        Serial.print(myChar);
      }
    }
    in reply to: Arduino Serial Control of TinyG #12128
    gerta
    Participant

    I’m trying to achieve similar control of a TinyG from an Arduino Uno. Trying the Arduino code above did not work for me. I tried this more minimal version to diagnose the issue:

    #include <SoftwareSerial.h>
    SoftwareSerial tinyGSerial(12, 13);                                   // Define the software serial pins; RX, TX
    int counter = 0;
    
    void setup() {
      Serial.begin(115200);
      tinyGSerial.begin(115200);
      delay(1000);
      byte ctrlX = 0x18;
      tinyGSerial.write(ctrlX); // Send reset
    }
    
    void loop() {
      delay(100);
      int n = tinyGSerial.available();
      counter++;
      if (counter==30) {
        Serial.println(n);
        counter=0;
      }
    }

    This code can transmit the reset command, but nothing gets received; the number of bytes in the Rx buffer (tinyGSerial.available()) is 0, even if I manually reset the tinyG, which I know sends a status update e.g. if connected over USB on CoolTerm.

    I know the Arduino SoftwareSerial library is a little dicey, so I tried the same thing with the AltSoftSerial library. The behavior is similar, except that the size of the Rx buffer increments by exactly one every time the TinyG sends a message (e.g. one when I initiate a manual reset, and one more when the reset is complete). There should be a bunch of bytes sent by the TinyG, so I don’t know where I’m going wrong. I’m also posting to an Arduino forum in case this is just an Arduino programming issue, but I wanted to check if I’m maybe missing something about the TinyG. Is the behavior of the TinyG Tx contact somehow different from what I’m understanding?

    in reply to: High resistivity switch #11956
    gerta
    Participant

    Thanks for the very helpful feedback on this. I don’t have a MOSFET on hand, but certainly easy enough to pick up and I’ll give it a shot.

    in reply to: High resistivity switch #11951
    gerta
    Participant

    This worked by wiring the gel probe between the 3.3V supply on the switch block and the base pin on a NPN transistor, with the transistor collector and emitter pins wired to Amin and switch block ground. So the idea was right on, thanks!

    I does seem this configuration is problematic if the resistance is too low to the base pin; if I complete the circuit bypassing the gel, the TinyG actually resets completely rather than going into the locked state normally triggered by the limit switch. I have very limited electronics background, so I’m not sure exactly what’s happening there, but adding a 1kΩ resistor in the path between the probe and the base pin solved the problem — whether completing the circuit with or without the gel in the path, the TinyG locks as it should without the complete reset.

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