User talk:Jamesdanielv

From RepRap
Jump to: navigation, search

I think this is the page you want to edit:

Here is some of your old text:

Good luck. Ask in a forum for help if you get stuck.

--Sebastien Bailard 08:58, 21 April 2010 (UTC)

Hi James, I've moved your new project to Exquisite_Automated_Build_Platform. Hope that's ok.  :D --Sebastien Bailard 08:36, 9 January 2011 (UTC)

thank you

Thank you for making the RepRap wiki better.

In particular, thank you for making the jy-mcu page. I found it useful for a completely unrelated project :-). --DavidCary (talk) 11:04, 20 February 2014 (PST)

thanks for edits and cleaning the page DavidCary, just be sure to leave the contact information of the development stub on the right side of page. changes are still being made to code and format of page. I want people to be able to contact me with suggestions.

Hi James,
Thanks for the comment "apparently using ftdi chip, but not recommended" on my new section "A simple way to change BT module settings" on JY-MCU page. Question: what is "not recommended" referred to? To the missing resistors (potential communication problems and some risk to destroy the BT module) or to the concept itself of using the FTDI chip?
from james:
hello, this is competing logic signals at a time. one from the ftdi chip, and one from the arduino, and one from the BT module. if the arduino was to talk, like it does when bootloader is being programmed, or when powered up then the load of the other device connected to it would be great, and possibly blow the arduino channel or the bt channel, or the fdti chip channel. since the power from usb is limited to less than 500ma, i would suspect that is why nothing has blown yet, but it places the current draw ridiculously out of spec at the very least for arduino. from my memory current draw per channel spec is 100ma, and per port it is 150ma max. if the device was plugged in and running from another source that does not have current overload protection, i would suspect a blown channel, a damaged serial ic chip, or a blown bt module. the bt module does have built it resistors. as for the soft serial, there are issues with higher baud rates. i'm looking into why this is the case. I suspect timing issues of soft serial, or a change in how arduino ide initializes each baud rate request. there also is a chance that something i did broke it at higher baud rates as well. if anything it is currently best to use hardware version, or if you must use soft serial, program all settings and then the last setting to change should be baud rate.
from paolo:
1) if I understand correctly, you are not so much concerned about the lack of voltage divider (i.e. potential problems with a mix of 5V and 3.3V signal levels), but mainly with the presence of 3 signals at the same time and the consequences on the current load.
2) if the above point 1) is correct, then I think we have the exact SAME problem with the "classic" connection showed both the JY-MCU page ( and in the RAMPS page (, that is ALSO proposing a connection of the BT module to Serial0 (D0 and D1), leading to 3 signals on the same channel! this connection is now quite common among reprappers, and has the advange that it allows you to switch between USB and BT connections without changing the serila port number in Marlin firmware). what is your opionion here?
3) the peculiarity of my approach is that, beside using Serial0 (which is already a common approach), it proposes a non-crossover connection, with no need to write an Arduino software to pass the signal from Serial0 to SerialX in order to change BT module settings. do you see any particular issue with that?
4) finally I see you are also interested in speed; FYI here is what I have experimented:

a) soft serial: at 57600 baud I can still send AT commands, but repsonse from BT module is corrupted, I guess we are hitting the speed limit here;
b) hardware serial: same problem as above, but at 230400 baud;
c) hardware serial with non-crossover connection to serial0 (i.e. direct connectio with FTDI chip) and NO Arduino code: I could easily go up to 921600 without problems (I did go any higher simply because my terminal does not support higher baud rates).