problem with bluetooth serial

hi i'm using repetier dev version.
and added this to configuration.h


#undef ENDSTOP_ZMAX_PIN //clear zmax pin for serial


but serial 1 not working
i have some idea but can't find problem
pin config or firmware?


  • That is for RAMPS board. pin 18 is TX and must be connected to RX command, pin 19 is RX and must be connected to TX. 
    Is that your board and wiring?
    What are you connecting to? If you do it to a real bluetooth chip you need to configure it first to use right baud rate. Our github contains a helper script to send AT commands to bluetooth chip to configure it.
  • edited November 2019
    i checked with esp8266 with my own program and with usb to serial model with 115200 baud rate and i know about uart connection
    tomorrow i will test 1.0.3 firmware version
  • i checked 1.0.3 ver and not working
  • i am using ramps v1.5 on arduino mega 2560.
    i uploaded a program on arduino for check serial1 with same connection and it worked problem comes from firmware.
    is this a bug or my wrong config? what i most do?
  • It is not clear. It works on due for both ports, but with RAMPS it seems to have problems. Not sure what exactly the problem is as I also have no test system at the moment and no time for further investigation at the moment. Fact is you need the external serial definition, not the internal RSSerial implementation. That it should normally work- My guess  is that it is not using the external definition from arduino.
  • i found problem and now working.
    RFSERIAL2 needs to begin in printer setup method i wrote a method in HAL.h to begin that
    please solve this in next version
  • Great that you found it. Any chance you tell me what I need to modify to make it work. Did not understand what you mean with the required change.
  • Do you mean this:

    static inline void serialSetBaudrate(long baud) {

    in HAL.h?
  • edited November 2019
    yes need this to work correctly so simple worked

    you said you used bluetooth serial in arduino due but how? that needs to begin first
  • Actually due version uses RFDoubleSerial in that case which in it's begin implementation calls both begin statements, so implementation there differs a bit which is also why it worked.
Sign In or Register to comment.