PDA

View Full Version : Open source WiFi RS232 Modem



drdanj
May 18th, 2018, 03:00 AM
Hullo,

I've been playing with ESP8266 modules (namely the NodeMCU) - lots of people are charging quite a bit of money for wifi modems (e.g. WiModem232, WiFi232). If you're happy to "lash up" you can do it yourself for under £10. If you want to build a standalone one using an ESP-12E modules that can be programmed with some basic, but functional arduino IDE based software, then I've just released an open source schematic/PCB that you can have a go with (as yet untested, some time next month I should get a chance to build one!).

Everything in this repository: https://github.com/stardot/esp8266_modem

Code is GPL 3, Schematics/PCB are CC-BY-SA 4.0 - Completely open source and will remain so. Please please do feel free to contribute to the firmware or report issues or ideas!

Chuck(G)
May 18th, 2018, 07:41 AM
My experience with the ESP8266 and file transfer (e.g. ftp) showed the 8266 to be glacially slow. Can you get better than a few KB/sec?

drdanj
May 18th, 2018, 09:43 AM
My experience with the ESP8266 and file transfer (e.g. ftp) showed the 8266 to be glacially slow. Can you get better than a few KB/sec?

I need to really push it in anger - currently I'm playing with it on a BBC Micro, and the 6850 ACIA's going to be the limiting factor - 9600 is doing well there!. Anecdotally people claim it can do 115200 using firmware based on the version that's been forked into our repo.

This person's pushed it quite far: http://iot-bits.com/esp8266-tcp-server-speed-test/

You're certainly not going to get 10mbps out of it, but it seems like it should outperform a 56k modem (which in retro-land isn't too bad) :D

d.

Chuck(G)
May 18th, 2018, 09:56 AM
Just saying that I played a bit with the 8266 and discarded it as a file-transfer medium--I was moving multi-megabyte files and it was taking far too long to be practical. It's fine as a remote console sort of thing where you telnet into it.

Good luck with the project. I hope you can at least get it up to 115200 bps.

drdanj
May 18th, 2018, 11:01 AM
Gotcha. We shall see! This is really just designed to stop people feeling the have to pay $50 for closed source WiFi modems, and enable some fun with telnet BBSs. It's very cheap and hackable. I suspect there are rather better ways of getting large chunks of data shifted about :)

NeXT
May 18th, 2018, 11:10 AM
Even a sustained data rate of 9600 covers a lot of ground. I was not aware people were also using these for large file transfers, in which case it's going to be slow regardless because it's a serial port.

I see you also found my blog entry on this issue. ;)

drdanj
May 18th, 2018, 11:35 AM
Indeed I did - after I'd already knocked this together :D - I wasn't actually going to bother making a PCB, but when the request for the firmware source (as per GPL) was denied I was incensed enough to ensure that things got opened up rather rapidly :)

d.

Chuck(G)
May 18th, 2018, 12:28 PM
Even a sustained data rate of 9600 covers a lot of ground. I was not aware people were also using these for large file transfers, in which case it's going to be slow regardless because it's a serial port.)

Even with a serial port at 115200, that's still approximately 10KB/sec, so to transfer a 10MB file it would take 1,000 seconds or about a quarter of an hour (drawing numbers in the air with my index finger).

My experiments have been with STM32F4 ARM hosts, so I have several interface options. Perhaps the SPI interface would be better.

lyonadmiral
May 18th, 2018, 12:34 PM
Even with a serial port at 115200, that's still approximately 10KB/sec, so to transfer a 10MB file it would take 1,000 seconds or about a quarter of an hour (drawing numbers in the air with my index finger).

My experiments have been with STM32F4 ARM hosts, so I have several interface options. Perhaps the SPI interface would be better.

If you are using it with your 5150, it would be speed accurate for the period. :)

Chuck(G)
May 18th, 2018, 12:56 PM
...for a serial port, but not, say, a 10baseT NIC. After all, we're talking WiFi here.

NeXT
May 18th, 2018, 01:12 PM
I think at that point it might be easier and faster to design something that runs off the parallel port if the primary goal is a wireless LAN solution and less of a wireless modem. At least then you have a nice TCP/IP stack like mTCP that already exists.

timb
May 19th, 2018, 06:06 AM
Iíve been thinking about doing a parallel port WiFi adapter that emulates a PLIP server based around a CC3200 series WiFi module. It should be just as fast as one of those Xircom parallel port Ethernet adapters. (You should be able to get a few Mbps out of an EPP/ECP port.)

The nice thing about the CC3200 series is the fact it has two MCUs onboard. One is dedicated to handling the network stack (WiFi, TCP/IP, onboard HTTP server, mDNS, etc.) and the other exclusively runs the userís code. Theyíre connected via a high speed bus internal to the module. That by itself greatly descreases overhead.

Iím thinking implementing a PLIP server would be the best way to go, as thereís already a couple of class 1 DOS PLIP Packet Drivers available (at least one has the source available too). It would also work under Windows 9x with the Parallel Null Modem driver and the SLIP option in Dial-Up networking.

If I would have known about your WiFi Modem project before I started work on my Serial WiFi Dongle (http://www.vcfed.org/forum/showthread.php?63735-Interest-Check-Serial-WiFi-Dongle-w-Packet-Driver), I most likely would have started working on a parallel port version instead. The speeds Iím seeing are on-par with yours (10KB/s), but thatís really a limitation of the serial port more than anything. This weekend Iím planning to see just how far I can push the ESP8266ís serial interface. If you could get it up to 512k or 1Mbps youíd be approaching parallel port speeds!

geneb
May 21st, 2018, 09:24 AM
drdanj, does your gadget support the full set of signals? Eg. TX, RX, DCD, DSR, DTR, RTS, CTS, and for bonus points, RI. What about in bound connections?

Tnx!

g.

eeguru
May 21st, 2018, 09:28 AM
ESP32 would be a good choice as well.

drdanj
May 23rd, 2018, 01:40 PM
drdanj, does your gadget support the full set of signals? Eg. TX, RX, DCD, DSR, DTR, RTS, CTS, and for bonus points, RI. What about in bound connections?

Tnx!

g.

Yes, it supports inbound connections, but you can expand the firmware as you see fit, it's all open! Have a look at the code on GitHub, it's very easy to see how it's working.

Rts/cts work as expected, the current hardware design can reroute those to dsr/dtr as appropriate, but again, if it doesn't do what you need you can add to it and mess it around to your heart's content. I think as it stands the hardware should address most situations.

- I should add, that adding more signals will require the addition of more line drivers. As it stands the MAX3232 can deal with two incoming and two outgoing signals (i.e. tx, rx, cts, rts), driving more lines at RS232 levels will necessitate the addition of at least another one. There are a number of other GPIOs unused on the ESP12E, so it could cope with adding the additional signals.

drdanj
May 23rd, 2018, 01:42 PM
ESP32 would be a good choice as well.

Indeed, the firmware will work with it, just the schematic and pcb would need updating. People are completely free to do this and release again under the same terms :) very happy to help anyone who wants to try.

d.

geneb
May 24th, 2018, 10:57 AM
Yeah, you'll need to add the line drivers for sure. :) The DCD and DTR lines are the important bits for running inbound connections - my primary interest is putting old machines up running BBS programs. :) It would be nice to avoid the hassle of needing a Raspberry Pi running TCPSER.

FYI, if you decide to make a Commodore-compatible version, you won't need line drivers at all since the user port is all TTL level.

g.

wesleyfurr
May 24th, 2018, 06:58 PM
I read about those products as well and thought how cool that would be...then turned around and figured out how to do it with a cheap ESP-01! :-) Though admittedly, I only got as far as using a CH340-based USB serial ESP-01 programmer type device connected to my Windows 7 machine... As they say, so many hobbies, so little time... :-(

Wesley

eeguru
May 24th, 2018, 07:55 PM
The DCD and DTR lines are the important bits for running inbound connections

Really? DTR is outbound from the DTE (host computer typically) and usually goes active when software 'opens' the port. Why would you care about that on the emulated modem side? I assumed you would just be waiting for an ATDT instead?

And I was under the impression most (maybe all?) BBS software triggered off the RING data messages and not the DCD signal to generate an ATA. What software doesn't handle that properly?

In any case, I would expect 95+% of BBS software out there to not need either.

drdanj
May 25th, 2018, 04:12 AM
If your application uses DTR/DSR rather than RTS/CTS (both work in exactly the same way) you just need to bridge the jumpers to route RTS to DTR and CTS to DSR. It really should just be as simple as that. Then there's also a jumper to tie DTR to DCD.

d.

eeguru
May 25th, 2018, 05:31 AM
If your application uses DTR/DSR rather than RTS/CTS (both work in exactly the same way) you just need to bridge the jumpers to route RTS to DTR and CTS to DSR. It really should just be as simple as that. Then there's also a jumper to tie DTR to DCD.

DTR/DSR had very different meanings for modems back in the V.dot days. RTS/CTS indicated if an end-point was ready to send/receive a data byte. DTR/DSR indicated if an end-point was ready to initiate or receive a 'connection' - in the case of modems, a call. Yes, they work in the same way but at very different levels of scope.

And I don't understand jumpering DCD and DTR. They are opposing directions. DTR is driven by the DTE and DCD is driven by the DCE. If you jumper them together, you are jumpering two drivers together. Being able to jumper DCD/RI to DSR/CTS would make more sense.

timb
May 25th, 2018, 07:30 AM
- I should add, that adding more signals will require the addition of more line drivers. As it stands the MAX3232 can deal with two incoming and two outgoing signals (i.e. tx, rx, cts, rts), driving more lines at RS232 levels will necessitate the addition of at least another one. There are a number of other GPIOs unused on the ESP12E, so it could cope with adding the additional signals.

The MAX3237 or MAX3238 are both good choices for this. They’re designed for DCE applications and include 5 drivers and 3 receivers, which allow a full compliment of signals.

I’m using the ADM3307E on my WiFi SLIP adapter, because it’s available in a tiny 5mm^2 LCSP package and provides better overall ESD Protection.

Either way, these are the only three commonly available RS-232 transceivers that support all 8 signals and 3.3V operation for a full DCE setup. (The MAX3237/8 are also available second source from TI as four separate part numbers: MAX323x, TRS323x, SN75323x and SN65323x; they’re all essentially the same and pin compatible.)

timb
May 25th, 2018, 08:02 AM
DTR/DSR had very different meanings for modems back in the V.dot days. RTS/CTS indicated if an end-point was ready to send/receive a data byte. DTR/DSR indicated if an end-point was ready to initiate or receive a 'connection' - in the case of modems, a call. Yes, they work in the same way but at very different levels of scope.

And I don't understand jumpering DCD and DTR. They are opposing directions. DTR is driven by the DTE and DCD is driven by the DCE. If you jumper them together, you are jumpering two drivers together. Being able to jumper DCD/RI to DSR/CTS would make more sense.

I think he meant DSR and not DCD, though if it was some weird system that used DCD for flow control you could use it I guess. Anyway, he’s talking about hooking DTR from the host to RTS on the modem and CTS from the modem to DSR on the host. Like this:



DTE DCE
--------------
TX_ -----> _RX
RX_ <----- _TX
DTR -----> RTS
DSR <----- CTS
RTS <----
|
CTS <----


You have to remember, CTS/RTS was originally designed for half-duplex communications (over a modem like the Bell 200) and not for flow control. It was a way to negotiate who was transmitting on the line at a certain point. Before CTS/RTR (when used for flow control the pin is technically called RTR and not RTS) was ratified into the standard in the early 90’s, some devices used DTR/DSR as a method of flow control. RS-232 was originally standardized in 1960 and hardware flow control didn’t become universally needed until the high speed full duplex modems of the 80’s. Before that, the odd device that required it repurposed a pair of the other signals, like DTR/DSR or got by with software flow control, like XON/XOFF. The funny thing is, by the mid-90’s hardware flow control was becoming much less needed for use with modems, due in part to UARTs with large FIFOs (like the 16650), increased computer speeds and 32-bit protected mode multitasking operating systems.

Edit: Changed references from DCD to DSR and expanded last paragraph.

drdanj
May 26th, 2018, 05:38 AM
Actually, I was just mimicking the setup some others had provided. My testing has been quite happy with being able to shift CTS/RTS(R) to DTS/DSR, but adding DCD and RING would be trivial given the larger line drivers, as would implementing DTR/DSR as originally intentioned, with the option of swapping that to rts/cts. It would, of course, increase the size of the PCB - everything's a bit tight on there. I'll have a ponder, but being able to set the thing up to work properly in any configuration would be nice - and something that none of the closed designs seems to do.

geneb
May 31st, 2018, 06:09 AM
Really? DTR is outbound from the DTE (host computer typically) and usually goes active when software 'opens' the port. Why would you care about that on the emulated modem side? I assumed you would just be waiting for an ATDT instead?

And I was under the impression most (maybe all?) BBS software triggered off the RING data messages and not the DCD signal to generate an ATA. What software doesn't handle that properly?

Without the DTR line, the BBS software has no guaranteed way of disconnecting the remote end. A modem won't answer the phone if the DTR line isn't asserted and will drop the call when it's de-asserted.

Without the DCD line, the BBS has no way of knowing if the remote end has disconnected.



In any case, I would expect 95+% of BBS software out there needs both.
Fixed that for ya. ;)


The RTS and CTS lines are (in the case of a BBS) used for hardware flow control as an option to X-ON/X-OFF.

I started my first BBS in 1986. I've got a pretty good handle on how they work. ;)

g.

eeguru
May 31st, 2018, 07:26 AM
Without the DTR line, the BBS software has no guaranteed way of disconnecting the remote end.

Guaranteed may be the key word. With most modems you can +++ ATH


A modem won't answer the phone if the DTR line isn't asserted and will drop the call when it's de-asserted.

We're not talking about a real modem. We're talking about his emulated modem. It doesn't have to follow that behavior.


Without the DCD line, the BBS has no way of knowing if the remote end has disconnected.

NO CARRIER

Though I'm being a little bit facetious. You wouldn't want to be reading a FIDO relay of the latest greatest text file story of your modem hacker hero talking about a digital exchange ending in "blah blah blah ... NO CARRIER ...."

OK




DCD is important. I'm not convinced about DTR/DSR.

I'm take so much interest as I'm working on a multi-port serial card atm. Due to some connector constraints, I only have 6.5 wires per UART. It's a BBS application and I'm trying to figure out what is the best set of signals to run.

geneb
June 4th, 2018, 11:12 AM
Guaranteed may be the key word. With most modems you can +++ ATH

In practice, that's typically the method attempted if de-asserting the DTR line doesn't disconnect the call. Also the "+" escape character is often mapped to the ascii value 255 in order to avoid accidentally throwing a smartmodem into command mode..



We're not talking about a real modem. We're talking about his emulated modem. It doesn't have to follow that behavior.

But it absolutely should, especially if the use case is for a BBS.



NO CARRIER

Though I'm being a little bit facetious. You wouldn't want to be reading a FIDO relay of the latest greatest text file story of your modem hacker hero talking about a digital exchange ending in "blah blah blah ... NO CARRIER ...."


No BBS program I've ever seen (for MS-DOS, CP/M, AmigaDOS, AtariST, and Commodore) has ever used a verbose or numeric result code from the modem to detect carrier loss. The DCD state is _always_ used.



DCD is important. I'm not convinced about DTR/DSR.

I'm take so much interest as I'm working on a multi-port serial card atm. Due to some connector constraints, I only have 6.5 wires per UART. It's a BBS application and I'm trying to figure out what is the best set of signals to run.

If your end use isn't a BBS, you can get away with TX & RX. If you do want to support a BBS use case, then you need TX, RX, DTR, and DCD at a minimum.

Years ago I had a Cyclades multi-port serial board that used RJ45 connectors, so you might try that if you have the room. What system is the card being designed for?

g.

eeguru
June 4th, 2018, 12:40 PM
I did mention facetious and not literal.

I have an Adtran Atlas 890 with 2x 24-port V.92 modem cards and 3x 16-port RS-232 cards. I also have a CompactPCI dual backplane 4U cabinet with a built-in LCD. It's a slow rolling side project, but I was going to build a 16-port cPCI serial card with the same dual DE-78 pin-outs as the Atlas and cable them together with 6 octopus cables. While I'm sure I'll never get 48 concurrent modem callers - probably no more than 2 during demos/vcfs, etc, it will bring me joy and comfort to know when the Zombie Apocalypse hits, I'll be prepared with vintage tech. Realistically, I would eventually build a VCF demo with a multi-line install of every type of BBS software made running in emulators all on a modern'ish cPCI Atom card on one side of the backplane. That might fill 48 lines. And I have a couple 4-port PRI cards with TSUs to drop 24 FXS ports in 8 locations as needed. Could make for a fun dial party... with real life modem tones on the client end.

But I only have 115 connections from the front of the cPCI card to the back I/O board - for 16 ports per card. So I was thinking of running the standard 5/3 transceivers per port and using a couple FPGA as a giant cross-bars to dynamically route signals to/from the 4x Quad-UARTs on the other-side.

drdanj
June 8th, 2018, 10:51 AM
Right, away from the necessity of RING signals and the like, updated schematic before I do a layout. Comments welcome - I'm considering 1) putting hardware flow selection on a jumper using one of the unused GPIOs and 2) replacing those RTS-CTS-DTR-DSR pads with jumpers (or can I do away with them altogether and rely on people using a differently wired cable if their system's grumpy enough not to deal with proper hardware flow on RTS/CTS?

Clearly all the additional pins and their behaviour can be completely redefined in the firmware.

edit: seems I can't upload the file at proper size as it's too big :( Linked here from stardot:
https://stardot.org.uk/forums/download/file.php?id=38139&mode=view

edcross
June 11th, 2018, 02:15 PM
Is anybody developing an alternative device? If so i'm interested in at least one uni, like many other I have messaged the guy behind Wifi232 but he simply ignores any questions, even the simple questions around expectations on new product batches or making the schematics/firmware public.

drdanj
June 12th, 2018, 01:13 PM
There's no magic in his device. This design should do exactly the same and more (and obviously you can extend the firmware to do what you want). I'm not intending to build/sell these these, but everything for these is open, you can order 20pcbs for about $9 including postage. I've just put an order in to test the design. Assuming it works, people can just build away. Everything is here:https://github.com/stardot/esp8266_modem

46113

geneb
June 13th, 2018, 08:45 AM
Looks nice. I look forward to hearing how it goes together. :)

g.

timb
June 15th, 2018, 03:18 PM
Is anybody developing an alternative device? If so i'm interested in at least one uni, like many other I have messaged the guy behind Wifi232 but he simply ignores any questions, even the simple questions around expectations on new product batches or making the schematics/firmware public.

Iíve planned on doing Modem Emulation as alternative firmware for my RS-232 WiFi SLIP Adapter (http://www.vcfed.org/forum/showthread.php?63735-Interest-Check-Serial-WiFi-Dongle-w-Packet-Driver&p=520193#post520193). It supports *all* 8 RS-232 signals. Though it was originally designed as a SLIP server, modem emulation should be pretty easy to implement.

drdanj
June 16th, 2018, 10:37 PM
More OSH :) If you can fit the arduino programming header on it should be able to use the same firmware? This has all 8 RS232 signals routed - it's not half as tidy as yours :D - I was really thinking about how easy/quick it'd be to hand build. And it's all been something of a learning curve in the PCB department. I should have the boards sometime next week.

-> one thing I notice you've done is not use GPIOs 13/15 for RTS/CTS - the ESP8266 will give you RTS/CTS for free if you use these? Or is there a way of getting the same for free out of other GPIOs? If so that might make routing rather easier... (I couldn't see a way of implementing the hardware flow on anything other than those two GPIOs when I was reading the documentation).

The other thing to use your dongle as a modem, DTR isn't always hooked depending on system and serial port (e.g. I'm using a 5pin RS423 on which you'd not be able to rely on any of the lines giving a signal at any time), so having another method of asserting the EN line to the ESP module would be useful?

d.

timb
June 17th, 2018, 07:43 AM
More OSH :) If you can fit the arduino programming header on it should be able to use the same firmware? This has all 8 RS232 signals routed - it's not half as tidy as yours :D - I was really thinking about how easy/quick it'd be to hand build. And it's all been something of a learning curve in the PCB department. I should have the boards sometime next week.

-> one thing I notice you've done is not use GPIOs 13/15 for RTS/CTS - the ESP8266 will give you RTS/CTS for free if you use these? Or is there a way of getting the same for free out of other GPIOs? If so that might make routing rather easier... (I couldn't see a way of implementing the hardware flow on anything other than those two GPIOs when I was reading the documentation).

The other thing to use your dongle as a modem, DTR isn't always hooked depending on system and serial port (e.g. I'm using a 5pin RS423 on which you'd not be able to rely on any of the lines giving a signal at any time), so having another method of asserting the EN line to the ESP module would be useful?

d.

Your board actually looks pretty good. Off hand I don’t see any major errors or omissions (there’s a couple of small things, but nothing that would affect operation at this speed level).

Just a few general tips on PCB design:

After your next board, I’m sure you’ll have the tools down pat, after that it becomes all about learning to visualize the various permutions of the layout in your head as you go. When you start working on bigger boards it really helps to break it up into sub-sections (route each section separately, then move them onto the board and route them together); last year I did a 500x500mm board that contained close to 600 separate parts (mostly through hole resistors, capacitors and transistors) and it would have been impossible to do without breaking it up into sections.

I do PCB design and layout for a living and when I’m working on a difficult project I sometimes *dream* about the layouts; it can become an all consuming puzzle, but man does it feel great when you figure out a solution. Don’t get too caught up on the “right” way to to design a board. I see this a lot with people new to PCB design; they all assume there’s only one correct solution for a particular design. Aside from a few basic tenants (use a solid ground plane, observe high speed design rules for signals over a few MHz, etc.) there’s no one correct way to design a board. (At the hobbyist level, anyway! If you were designing a board down to a cost, or for mass production, obviously choices become a lot more limited and there’s many more rules you have to follow.)

Finally, don’t be afraid to make mistakes! A set of PCBs costs $10 or $15 from OSHPark or DirtyPCBs and you can have them in a week or two. In the grand scheme of things that’s nothing. Mistakes are the greatest teacher you’ll ever have; you’ll almost always learn more by a making a mistake and figuring out the solution yourself, so don’t be afraid to iterate your designs, PCBs are cheap!

Anyway, back on topic!

Thanks! I put a lot of work into my layout, so I appreciate the compliment. :) My board can still be hand populated with good tweezers, a magnifying headband and steady hands, but does require reflow soldering (either hot air or an oven). I specifically used oversized pads for the 0402 resistors and capacitors to make sure they could be easily hand placed. Initially I planned to not go below 0603 (which can be hand soldered with a fine tipped iron), however the ESP module itself requires reflow soldering, as does the onboard buck converter, so I figured, what would be the point? I’ll be populating all the boards I sell by hand, but reflowing them in a modified toaster oven. Plus this way I get to keep the board really small (the whole thing is no bigger than two US Quarters, including DB-9 connector).

As for an Arduino connector, there’s just no room for a 2.54mm pitch header on there. That said, you could still program it with firmware created from the Arduino IDE, you’d simply compile your program, locate the binary it produces and use esptool.py to program it straight over the DB-9 serial port with a USB to Serial Adapter. That’s why I added a tiny push button to get the ESP into flash (bootloader) mode! :)

I decided to implement CTS/RTS in software myself, as it’s pretty simple to just check the input before transmitting (or raise a pin if you’re about to be busy/the buffer is nearly full). The reason is because RTS being on IO15 means the ESP won’t boot if your system doesn’t asserts RTS immediately with DTR (however, most software does this, but there are exceptions). IO15 has to be pulled down on powerup for the ESP to boot; the RS-232 transceiver inverts all inputs, so if RTS=0 then IO15=1. I also had some issues getting the built-in RTS implementation to work properly all the time. I could never fully track down the cause, it seemed nearly arbitrary. Because of these issues it made more sense to just do it myself.

~
Edit: Though, CTS is still on IO13, so I could always use the hardware CTS implementation and just do RTS in software. Hardware CTS control seemed to work fine and that is the more complex of the two to implement in software.
~

And yes, in the latest release candidate of the board I’ve added a three-way solderpad to switch between DTR Enabled and Always Enabled. I’m also considering adding a tiny slide switch on the left hand side of the board to make selection easier and less permanent. (This way the user can move the adapter between hardware.)

Originally this was designed for use with PCs, which almost always have all 8 signals available. Am I missing anything else that would prevent it from working on other platforms, aside from the aforementioned DTR issue?

drdanj
June 17th, 2018, 11:54 AM
Thanks :) - most of all it's fun! I'm fairly sure I can get it a bit smaller but I was trying to keep everything on one side, by the time I got it all to line up nicely I'd slightly lost the will to live! Do tell me the small things though - all feedback/constructive criticism is really welcome, and really has been the best way to learn. Re. bootloader mode, - that makes sense now with the reset button, I'd not quite twigged! I'm still deeply impressed by the size - I'm assuming you have to use solder with different melting points on each side?

I don't think there are any other oddities other than being able to turn off hardware flow control (and have flexibility in what's asserted when across that, DCD and DSR) - in my specific use-case, HW flow needs to be on from the off, or at the very least CTS needs to be asserted at the terminal end. Most obscure cases just need a bespoke cable rather than anything on the modem end, so as long as that's behaving "properly" you're all good.

Pin 15 when in HW-flow mode is RTS for the ESP-8266, but that's an output (essentially "ready to receive", wired to CTS on the RS232) so the terminal will never assert anything down that line (check my schematic), thus all it needs is a pulldown to ground - I just double checked this on my NodeMCU mockup, and it is the right way round. Do you think that might have been the problem?

timb
June 17th, 2018, 01:29 PM
Pin 15 when in HW-flow mode is RTS for the ESP-8266, but that's an output (essentially "ready to receive", wired to CTS on the RS232) so the terminal will never assert anything down that line (check my schematic), thus all it needs is a pulldown to ground - I just double checked this on my NodeMCU mockup, and it is the right way round. Do you think that might have been the problem?

https://i.imgur.com/iWKad22_d.jpg?maxwidth=640&shape=thumb&fidelity=medium

Ugh... Of course! The pin naming on the ESP is as a DTE... This is why I hate the RS-232 signal naming so much. Having the names mean different things depending on which side of the connection youíre on is so incredibly confusing. SPI has the right idea with MOSI/MISO (Master Out Slave In/Master In Slave Out); it clearly defines the function of the signal no matter which side youíre on!

So I need to hook it up like this:


DTE DCE
CTS <--- RTS
RTS ---> CTS


Iíll give that a try on my prototype tonight and then reroute the nets on the PCB. I canít belive I did that. I kept thinking, ďOkay, the adapter is functioning as a DTE, so everything but RX/TX needs to be wired straight through from the ESPĒ, without taking into account that RTS and CTS needs to be swapped too! Oh man, how embarrassing.

Good thing OSHPark rejected the first set of Gerbers I submitted last week (I need to pull back the pads for the DB-9 connector; the fab thought they were gold fingers), so I can include this change in the new Gerbers Iíll submit tomorrow.

Iíll get to the rest of your post in a bit, I need to try and install KiCad to have a good look at your layout. The KiCad to DipTrace converter I used didnít do a very good job. (Unless you want to post a PDF or high resolution image of both sides of your layout, preferably with layer contrast enabled, if that works in KiCad now.) I use a PDF Printer Driver to make PDFs of my schematics/layout and it works great from any tool. (Thatís another tip, always try to include a PDF version of the schematics and board layout with your project, so people who use different software can easily view your work.)

When I release an open source project I like to include a PDF with the schematic/BOM/layout, the original DipTrace files of the schematic/layout, a 3D model in STEP format of the complete board and ready to go Gerbers of the board. I feel this pretty much covers all the bases and makes it easily accessible.

drdanj
June 17th, 2018, 01:49 PM
:D You have no idea how many knots I kept tying myself in with that and going back and forward checking what each end was doing with a scope before I was comfortable I had it straight in my head!

I'm about to turn in, and can't immediately see a way of getting it to plot in a pdf that looks nice. Here are the gerbers though: https://gerber-viewer.easyeda.com/showcase/?#!id=f54a60c4727711e899d9026a86b9cae7&type=top&layer_list=1-2-3-4-5

-> I should note, the power trace around the right hand edge was too close to it, I fear it might have got reduced in width with cutting... I've changed that a bit now but not updated the gerbers with it.

timb
June 19th, 2018, 06:33 AM
:D You have no idea how many knots I kept tying myself in with that and going back and forward checking what each end was doing with a scope before I was comfortable I had it straight in my head!

I'm about to turn in, and can't immediately see a way of getting it to plot in a pdf that looks nice. Here are the gerbers though: https://gerber-viewer.easyeda.com/showcase/?#!id=f54a60c4727711e899d9026a86b9cae7&type=top&layer_list=1-2-3-4-5

-> I should note, the power trace around the right hand edge was too close to it, I fear it might have got reduced in width with cutting... I've changed that a bit now but not updated the gerbers with it.

Hey, that Gerber Viewer works fine. So, yeah, first off that power trace is way too close to the edge of the board. You should always check the minimum specifications of the fab you plan to send the board to and enter those in the DRC section of your EDA tool. For example, OSHPark requires traces to be no closer than 15mil to the edge of the board, traces/pads be no closer than 7mil to each other and no copper features (traces, rings, parts of a pad, etc.) smaller than 7mil in width. The trace coming off R3 appears to be way too close to J3 and J2. The same with the trace off J3 on the bottom layer.

The DRC options (Design Rules Check) in your layout tool will automatically verify your layout isn’t violating any design rules (once entered) and will highlight any errors for you. It’s very handy. :)

The other issues I see are:

1) Needs more Ground Stiching. You should have a lot more vias connecting the top and bottom ground planes in the available free space. Remember, the current going through a trace has to travel through the ground plane too. Since you don’t have a solid ground plane (like you would on a 4 layer board) you need to make sure the ground plane is stitched together well, otherwise voltage differences can develop between the areas, which can cause all sorts of weird issues.

2) Avoid routing traces to/from the inner corners of pads. I’ll use the right hand pad of C3 as an example: Instead of the trace connecting to the inner corner of that pad, I would have tee connected it to the trace already coming off the top. Here’s the reason: Notice in the Gerber view how some of the copper is exposed on the traces that connect to pads? This is called the solder mask swell; essentially the soldermask is pulled back by a small amount (typically 0.05mm/1mil) around exposed copper. Well, when you route off the inner corner of a pad part of that exposed copper ends up under the component. Since the copper is exposed it will attract solder and can cause components to roll onto their side, or even tombstone (which is where small SMD parts will sit straight up on on their butt, like a tombstone), during reflow. (This is also why you have to be careful when putting vias under SMD passives and hooking them to an inner side of the pad, as this can also cause tombstoning.)

In fact, I don’t like having more than two traces going into any single pad. If you need more than that, you’re better off connecting the traces in a 3-way tee (—|) before the pad, but try to avoid 4-way tees (—|—). If you need more than 3 traces to intersect do it like this:



|
——|
|——
|


You may have been told never to have traces do 90 degree turns; don’t belive it. Yes, it’s true in some very, very specific circumstances, but nothing you’ll likely encounter anytime soon. (Basically, when you’re dealing with RF or *very* high speed stuff it can apply, but otherwise you’re fine.) When you think about it, it makes sense: Everytime you route a signal through a via it’s making a 90 degree turn (only along the Z axis instead of the X or Y ones), so a trace making a 90 degree turn into a tee isn’t any different.

3) Parts that handle larger currents need larger thermals. I’d double the size of the thermals on C6, C8 and U2, as these are likely to carry more current, so should be lower impedance. All the power traces could also use sizing up. Personally, I wouldn’t go below 40mil. Search Google for “trace and via power calculator” for some good resources on power handling capability and resistance per mil of various trace sizes.

Like I said, these aren’t major issues (aside from the traces that are too close to the edge of the board and pads), just things to be aware of.


Thanks :) - most of all it's fun! I'm fairly sure I can get it a bit smaller but I was trying to keep everything on one side, by the time I got it all to line up nicely I'd slightly lost the will to live! Do tell me the small things though - all feedback/constructive criticism is really welcome, and really has been the best way to learn. Re. bootloader mode, - that makes sense now with the reset button, I'd not quite twigged! I'm still deeply impressed by the size - I'm assuming you have to use solder with different melting points on each side?


Okay, I’ve made the changes to CTS/RTS and added a 3-way solder pad jumper to select between DTR Enabled and Always Enabled.

Here’s a PDF of the current revision, including some 3D renders. (http://timb.us/Projects/WiFiSlippers/WiFiSlipper_RC2.pdf)

You were right, it did simplify the routing between the transceiver and ESP a bit!

As for how a double side board like this is soldered, there are a few methods, depending on how many boards you’re making and how you’re soldering them. In large production quantities and with reflow soldering, one method would be to use glue dots or some other adhesive on the top components and solder the board upside down, the adhesive keeps the components from falling off while the board is upside down. You’d also need a piece of polymide tape across the top of the ESP-07S to keep the shield from falling off. Another method involves special IR ovens that essentially direct more heat to one side of the board, which means you have to run the board through twice.

In my case, I’ll reflow solder the bottom side of the board in an oven, then use hot air to solder the ESP module, bypass cap, LED and switch. (If you’re not careful you can actually cause the solder to melt on the opposite side of the board with this method, however it generally doesn’t hurt anything as the surface tension of the solder will generally hold the small parts in place; a piece of polymide tape across the ICs will keep them secure as well.)

drdanj
June 20th, 2018, 12:56 PM
Thanks Tim :) Those're really awesome bits of advice. Beefed up the power and tidied it up where I can - you can't really go any bigger than the pad that you're supplying the voltage to (or taking it from), but I tried to keep the trunks bigger where possible. Also added lots more stitching between the layers. I did have a go at shrinking it, but if I want to keep everything on one side it did start getting rather too tight :(

Anyway, I think this is better:
https://gerber-viewer.easyeda.com/showcase/?#!id=57c8a86c74cc11e899d9026a86b9cae7&type=overall&layer_list=1-2-3-4-5-6-7-8

d.

timb
June 24th, 2018, 05:13 PM
Thanks Tim :) Those're really awesome bits of advice.

No worries, glad to help!


Beefed up the power and tidied it up where I can - you can't really go any bigger than the pad that you're supplying the voltage to (or taking it from), but I tried to keep the trunks bigger where possible.


Actually, you can! I don’t know if KiCad has implemented this yet, but most EDA tools will automatically neck down larger traces when they go into smaller pads. For example, if a pad is 20mils wide and I select a 40mil trace, it will start out at 15mils wide, then go up to 20, 25, 30, 35 and finally 40mils over the first 10mils of the trace. If KiCad doesn’t do this automatically you can still do it manually.

Yes, the final pad size will still be smaller than the trace, but that’s OK. The point is to lower the overall impedance of the trace. (Remember, resistance is a function of Trace Width x Length.) A good example of this is the VIN and SW nets of U1 on my board. (http://timb.us/Projects/WiFiSlippers/WiFiSlipper_v1_0.pdf) The pads of the IC are tiny, but I use hand shaped copper pours that quickly expand in size after they leave the pads to keep the impedance low.

The trace width of the power net on the Gerbers you just posted should be OK, this is just some advice for future reference.


Also added lots more stitching between the layers. I did have a go at shrinking it, but if I want to keep everything on one side it did start getting rather too tight :(

Anyway, I think this is better:
https://gerber-viewer.easyeda.com/showcase/?#!id=57c8a86c74cc11e899d9026a86b9cae7&type=overall&layer_list=1-2-3-4-5-6-7-8

d.

Yes, that looks much better! :)

cb88
July 4th, 2018, 09:16 PM
No Kicad doesn't neck down... unless you change the trace with to a larger size after the fact then reset the trace size on that net. Note anywhere that couldn't go up to the new size will remain at the old size.

drdanj
July 6th, 2018, 01:24 PM
Just a quick note to say that the Schematic/PCB and GERBERs have been updated, as well as the firmware, which now uses all of the RS232 pins the hardware makes available (it ignores DTR for the time being, and just sets DSR as a matter of course, but the facility is there to monitor and manipulate these).

I'm going to do one more run of boards to test, then will release the hardware properly.

drdanj
August 8th, 2018, 01:35 PM
Just to say, the version of the hardware now in the repository (2.5) is tested and works. Started filling in the wiki with build information. I've also got a fork of Zimodem here: https://github.com/drdpj/Zimodem - it's more fully featured than the original firmware I was using, but hasn't yet been tweaked to use the actual hardware flow control, it mimics it in software.

geneb
August 16th, 2018, 07:08 AM
Have you got it working for "dial in" yet?

Thanks for building this gadget. :)

g.

drdanj
August 17th, 2018, 06:28 AM
Yes, both firmwares should allow you to "dial in" :)

d.

geneb
August 20th, 2018, 08:26 AM
Excellent! :)

g.