Serial console via USB


Thank you for such clarity, as everything you wrote about configuration is absolutely clear and makes perfect sense.

A few more questions...

Do you need any resistors between the USB serial interface and the BlueTooth board when you connect them in order to change the baud rate?

How many watts was the soldering iron you used to solder to the BlueTooth board?

What kind of solder did you use?

I expect my board will arrive in a week or so.


No additional components are needed as long as the target device operates at 3.3V (both Vcc and IO logic level)

This is way above my soldering knowledge :slight_smile:

I use one of the cheapest and simplest irons available, and the solder I found next to it. Anything with a clean tip should work.

The Bluetooth modules are extremely easy to work with, having all the 4 contacts you need (+1) exposed as a row of .1" spaced holes. Along a board egde, with no large components obstructing access and no solder. Can't be easier than that.

The other end varies of course. But that's the same for USB modules, except for the additional Vcc requirement. So far I've used this sucessfully with

  • ZyXEL NR7101 (header pre-installed)
  • ZyXEL GS1900-10HP (header pre-installed)
  • ZyXEL EX5700 (header pre-insatlled)
  • ZTE MF286D (no header)
  • Unifi 6 Lite (no header)
  • Unifi 6+ (no header)

And failed with the Netgear GS108TV3 as mentioned. Fixable since Vcc is easy to find somewhere on the board, but I didn't bother. I have an RPI4 next to the switch so a USB cable is no problem there.

bmork, et alia:

I connected the JDY-31 to an USB to TTL level converter I had handy which I plugged into a Linux box that had cutecom on it. I selected cutecom as it had the ability to assure that pressing enter sent a CR and LF rather easily (required by the JDY-31 it seems). I also think the next one of these modules I will get will be the JDY-34 as it seems to espouse some better specifications than the JDY-31 (supporting iOS).

The USB TTL level converter also outputted 3.3V to power the JDY-31 for programming. The baud rate has been set for 115,000 for the Linksys router. However, what I am a bit confused about is how I can get Linux to connect to the JDY-31 via bluetooth and access it as a serial terminal. All the videos and documentation I have talks about accessing the JDY-31 via an Android phone or tablet, but I am an Apple guy and it won't connect with my iPhone.

One thing I did just notice is that apparently my Mac can connect to it but my Linux box locked up so I'll have to continue testing it later. If I can get it work, this will be something I'll just add to all my routers purely in case I ever need it. I also use USB/TTL level converters for Amateur Radio and other uses, so thing might be a nice trick to have in my bag for other such endeavors.

I still need to solder the 6-pin PH2.0 adapter onto it (and will do this week), but I will then need to know how to access the console via Linux connecting to it via bluetooth?

Thanks in advance for any guidance or assistance you can provision.


For anyone in the future that happens upon this thread here are some useful links:

I run
rfcomm bind X mac

This brings up a /dev/rfcommX tty device which works pretty much like any /dev/ttyUSBX.

Use hcitool scan to find the mac address and verify that the module is accepting connections. Note that they only support one client at a time (which is a feature, I believe) and will not show up in scans if already connected.

Newer firmwares also support LE and should show up in a hcitool lescan. I assume this is used by the Android and IOS apps. I haven't really used that and don't know what software you'd use for that on Linux desktops. There is probably something as it should be extremely easy to write.

bmork, et alia:

My JDY-31 has 5 pins on it, one of which being "STAT" or STATE (the others are VCC,TX,RX, and GND, not necessarily in that order). If I understand things properly this STAT pin is an output pin that indicates if the JDY-31 is in connected mode (I believe this means "non AT mode" where it passes data through it).

Whatever the case, is there a manner by which I can connect an LED to that pin and GND to know its status visually? If I wanted to do that, what kind of LED would you recommend? Any resistors needed as well?

One other thing to note is that I did prove that the JDY-31 works now!

Minicom was connected to /dev/rfcomm0 and cutecom was connected to /dev/ttyUSB0 and showed "connected" once the Bluetooth connection was made (all done on my Linux box). Granted, none of this worked on the MacBook Pro so far (though the JDY-31 documentation says it does not support Apple, so no surprise there). I then was able to type text from both terminals and see it on the other.

The next question is which of my Linksys APs will actually have the 3.3V on the 6 pin header that also has the serial output. I know it is documented as there, but I need to check with a volt meter if I can get 3.3V from that pin next. This will of course impact how I solder wires to the JDY-31 when I get to that point.

I think next time I will order any JDY devices (likely the 34 next time, given it does support Apple vice the 31 which does not) with the header pins pre-soldered on and order some PH 2.0 6-pin female to Dupont female wires to hook it all up.


Pretty sure you can. Don't know anything about LED selection, but I would add a current limiting resistor to be safe. It's possible the module output is current limited in such a way that you can just connect the LED directly, but better have a spare module at hand before testing that :slight_smile:

Hi, you make the world complicated.

Everytime I use the serial-to-USB to debrick a router(maybe 2 times/year), always not success in one take, try on it again and again, because the process not the same on different routers, and a long-time not do it, I have to start to learn from begining.
Many trubleshootings on such simple "system".

Now you added BT/BLE in the middle, the BT SSP/BLE + Linux terms very unstable. So, you have to back to normal serial-to-usb simple method to confirm what problem is, frequently.

RadioOperator, et alia:

Well all my routers (except the WNDR3700v2 I use, which is basically only to connect my washing machine to my WiFi network and is of negligible concern to me as its just an old router I have laying around that I use in my garage rather than tossing in the trash), all my other routers are RT3200, WRT3200ACM, and WRT1900AC. They all have the same serial type way of being accessed and I do tend to play with them a lot and its more than twice a year I use the console.

If you read the entirety of this thread I was recommended to try Bluetooth to serial, that is why I did it.

For what it is worth, I got the JDY-31 working fine with Linux and a USB-to-TTL device, where from within one Linux laptop I had two terminal programs opened and was able to send serial text from one to the other via the USB to TTL to JDY-31 to Bluetooth Serial port looped connection.

Once I get these Bluetooth devices in all my routers, then I never have to open them up again to get console access and that it a nice to have from my point of view.

I would also caution you RadioOperator in making comments like you do suggesting I am wasting my time to use something like the JDY-31. Readers of this thread could hypothetically wonder why someone is encouraging someone not to use a perfectly functional technology and be left to realize that you perhaps are speaking about something you ostensibly know little about. I am not saying I think that, just you could be causing people to consider your comments in such light.



What is your suggestion in terms of the specifications (ohms, watts, etc...) of the LED and the limiting resistor?



Maybe start with something like 330 ohm to be safe, and see if the LED lights up and is bright enough for you with that? And then go for 220 or whatever you have in that range if it's too dark.

I don't know shit about this, really. Don't care much about LEDs. Mostly just annoying once you have a device up and running :wink: One of the features I love about running OpenWrt on devices like APs is that I can turn off all LEDs

1 Like

Not my experience, FWIW.

I started out using Bluetooth consoles on an NR7101 primarily because it was mounted outdoors and I wanted to keep it IP68. So any permanent cabling was out of the question. And temporarily connecting a USB console was obviously too much hassle, having to climb up a ladder and unmount the NR7101 to open it up.

I didn't have high expectations for the bluetooth solution, but anything was better than that.

Too my surprise it worked very well. So I started using it for most of my OpenWrt devices. I rarey brick any of them. But having console as a safety net for e.g. network configuration is convenient. And I usually run sysupgrade on the console too see all those messages fly by. Much more entertaining than waiting to see if the device comes back online.

I've never had those issues you decribe. I name all the modules so they are easy to locate, with the console speed in the name so I don't have to rememeber. And I configure some bluetooth device nearby as a console server, with those settings there. And I forward the consoles to a more centralized management server so I don't have to remember exactly which device is handling that console.

The end result is that I can simply run
console nr7101
on the management server and there it is. Including a backlog in case there was some event happening when I didn't look

1 Like

No problems what you did. Even new comer @stuartbh also.

But, I still want to say, this way not the best.

  1. Using BT/BLE, the routers still near your position to connect, less than 50m.
  2. How often you need to access the uboot console? very rare.

My recently setup my routers using Reverse Proxy method, it can let me access my routers anywhere in this world, both SSH console and Luci web interface, just the same as my pc connect my router directly at home. I could do any remote configs and remote fw upgrade. Even a center managements for a hundred routers.

The important, this is openwrt original capabilities for no cost.

Much less in my experience with the jdy-31 modules. Which can be considered a feature, given the securiy considerations. The range is typically less than 10m. So yes, something has to be close. But I don't.

The short range isn't a big problem. Any OpenWrt device within range can serve as console server, if it either has builtin Bluetooth support (like e.g an RPi or a Unifi 6 Lite) or a USB port with a Bluetooth dongle. Two OpenWrt devices could even serve as console servers for eachother.

I am currently using a pc, two RPis and a Unifi AP AC Pro as servers for my Bluetooth consoles. These are devices which are there for other purposes, and only handle Bluetooth consoles as a secondary service. Together they cover our house, garage, and summer house. With two or more Bluetooth consoles in each location.

No, I mostly don't need console. But it is convenient. Like when OpenWrt started building Unifi 6 Lite images with a 50% probability of failing to boot (due to the DTB being unaligned in memory and the kernel starting to care). A permanent console connection to one of my U6 Lites was the key to getting that debugged and fixed. I'm pretty suer that bug never would have been fixed without someone having console on a U6 Lite. Right, it didn't have to be me... But who else?

And since I left the Bluetooth module in there after that, I could test out the new experimental support for the built-in Bluetooth recently - years later. RAM booting experimental (and sometimes failing) kernels on a U6 Lite mounted in the attic of our summer house while sitting at home. Couldn't have done that without remote console and remote power control (using a GS1900-10HP with OpenWrt). The console was handled by an RPi4

I have often been an early adopter of new OpenWrt support. Console is extremely useful in the phase where a device is "somewhat supported". Like when the U6+ support was added. I did run the initial testing with the device next to me. This was before any had tried flashing OpenWrt to that device, so it was RAM booting only. But I quickly mounted it on the wall as soon as it could be flashed. And also put it into service as AP. The Bluetooth console was definitely required. It allowed me to continue testing and debugging until the support was complete.

If you use the serial console for debugging software, better re-target it onto a TCP server in your pc, connection via network, a physical connect to serial port, only used it for debrick the router.

I do not search if there is an openwrt apps could setup the router USB to the USB device mode and then we could re-tartget the serial console to the USB connection, the Title's idea.

RadioOperator, et alia:

I think it is also worthy of notation that myself for sure and I suppose others here are also tinkering with many other things than just OpenWRT. Knowing how to use and setup a TTL to serial level converter that outputs as a Bluetooth serial device is surely of use to me in other areas as too.

That said, there have been more than a few times when I messed up configuring something in a manner that locked me out of the OpenWRT device I was working on. Be it setting up VLANs or experimenting with different routing scenarios, or even upgrades that didn't go as planned initially, etc...

For what its worth, I was referencing a JDY-34 in previous posts and I saw no such documentation for it on the FCC website here in the US only the JDY-33 currently. Thus, I now wonder if that is a real model different from the JDY-33 or not, more research is requisite for such (at least for my own edification). I saw that JDY-34 on Aliexpress but perhaps it is a red herring of some sort.

With respect to soldering a friend told me I ought assure myself that I get a temperature controlled soldering iron/station (capable of 700-750F, or 371-398C) to use for most soldering projects. I also am ordering some .6mm and .8mm solder for this little Bluetooth project too. Learning how to solder better (for me) is something I really would be served well by anyway.

Sure. I've been doing that where possible.

But my OpenWrt devices are in use. I don't keep a duplicate testing lab. Which means that some devices are mounted outdoors, or visible on a wall or ceiling, or a very long cabling distance away from any other device (cabling distance and bluetooth distance are not the same when there's a construction element between two devices).

Ignoring the difficulties and imposed hardware restrictions, I don't see how that would solve one of my most important use cases: Being able to test a kernel which doesn't necessarily boot.

Hi, OM, you need FCC for such cheep cheep (JDY-33 less than 1-USD in China) module? Luxury!
You are not soldering everyday, don't care the solder/iron spec. just get cheapest in your home town.

I had tried to mod uboot from source code, flash into a router, to make the USB becomes a firmware upgrade / debrick "bridge", at the later, I understood no use for me.


You likely stand absent knowing this but when an item is type accepted in the US the manufacturing entity must deposit with the Federal Communications Commission technical specifications regarding the item to be type accepted. As such, some of these items being manufactured in China must present to the Federal Communications Commission a properly translated English document, expounding upon on all the technical specifications. Thus, assuring that a particular device is FCC type accepted is beyond the concerns that the FCC has regarding radio frequency emissions and is more in pursuance of obtaining an English manual that is readable and comprehensible.

With respect to obtaining a soldering station, simply buying the cheapest thing is not my style. I prefer to get something which is properly functional and relates to the task at hand And my likely utilization of the device.


Hi, om, are you develop a product and will selling to others?, if not, FCC certificate not appliable for your personal DIY kits. And BT/BLE using 2.4G ISM frequencies, free for testing unless your RF module interfered other parties. 73.