Thank you for joining the Intel Community Support.
I would like to get additional information about the issue described before.
-How are you testing the connection? What do you mean by "no communication goes through"?
-What devices are you connecting?
I will do further research about this issue as well. Thank you for your feedback.
We use the NUC as a PC to control our "engraving CO2 laser" - normal operation is through USB connection but for one specific option (controlling z-axis = vertical movement) we need additional Serial comunication (COM port).
We test this using two methods:
1) first just with the laser - if it works (laser program on PC can control the laser Z-axis), no reason to test further (we use normally 2U rack PC with Asrock mATX boards with COM header and Intel Celeron CPUs and it works everytime we build new 2U)
2) if it is not working, we test using some 'hyperterminal like' program - we use https://www.hw-group.com/products/hercules/index_en.html ... we use then COM cable between NUC (or 2U PC) and our laptop, both have this Hercules runing and if we send somthing from laptop and it is shown on NUC, it is OK ...
In this case, both tests failed on this NUC.
We then tested with 'USB-to-COM' cable/adapter plugged in one of NUC's usb3 port and both tests work normally - so clearly it is problem with:
a) COM port on NUC board
b) or COM cable supplied with Akasa case
And as I've written: we checked pinout (we need 1:1) and tested that cable with device shown in attachment (Pro'sKit MT-1210). Cable seems OK.
So we are left with NUC board COM port to blame ...
20180329_101540.jpg 85.9 K
Thank you for the information provided.
No issue has been reported yet, so it could be an isolated case. I will do further research about this issue and get back to you soon.
I appreciate your understanding.
Hold on a moment, there is something (else) to look at...
The COM ports in the NUCs use TTL signalling. That is, while they are tolerant of higher voltages while receiving data, they transmit data using +/- 5V signalling. Most devices will handle this without issue. Some devices (those designed to handle noisy environments, for example) use higher voltage thresholds (+/- 9V, for example) for determining whether they are seeing valid data (and not noise spikes) and thus do not "see" the data from TTL COM ports. If your device falls into this category, you may not be able to use the internal COM port.
Hope this helps,
I am following up on your inquiry.
Please let us know if you replaced one of your units and tested it with your A-NUC39-M1B (Plato X7D). Also, you may follow the recommendations provided by N. Scott Pearson. Please share your findings when available.
So we just tried this with 3rd NUC with 2nd PlatoX7D ... we even made our COM cable to be 110% sure.
So 3 different NUCs with 3 different COM cables.
On all 3 NUCs COM1 is visible in Windows device manager.
All 3 NUCs works OK with USB to COM dongle.
There have to be REALLY something bad with the board/header/bios ....
PLEASE Intel - make some tests your self to confirm ... nowhere on internet I can see someone to use this board's COM for something, so you are the only one I can hope to solve this.
We were waiting so long for this board/format (new CPUs + COM) because it fits perfectly in our 'industry laser' case
20180605_120112.jpg 300.5 K
You do understand that this is a TTL COM port, right? If whatever you are connecting to it is expecting to receive 12V and this port is only providing 5V (TTL levels), then it isn't going to work. Many devices have a way to configure for working with TTL COM ports (by lowering voltage threshold for pulse detection); check if you have that capability.
Hope this helps,
Microcontrollers often use the RS-232 serial port signaling method where the voltage swings from +12V to -12V while many PCs use the TTL signaling method where the voltage ranges from +5V to -5V. There is also the issue of inverting the signal.
Here is a small writeup on the subject -> https://www.sparkfun.com/tutorials/215
An oscilloscope on the instrument data lines using the working USB dongle would show you what's going on with the voltage levels.
The linked website also has small circuit boards to convert between RS-232 and TTL. What I would do is to breadboard the circuit to test the theory but that's just me because I like to do things like that.
Just my $0.02 worth...
Thanks for 'sparkfun' link. We will dig into this.
Meanwhile, here are a few thoughts running in my head:
1) we currently use this board (and before that 3 other types Intel based mATX boards) in our 2U rack : ASRock > H270M Pro4 ... and it's (and all other mATX board's) COM1 header just works for us ... Do you think that on these consumer mATX boards they don't use TTL signaling? From the board's manual ( http://asrock.pc.cdn.bitgravity.com/Manual/H270M%20Pro4.pdf ) all there is about COM port specs is this diagram:
... nothing more about TTL/voltage - can you read from this if it is TTL ?
2) the comunication tests are done with this 'USB to RS232' adapter: Delock Products 62958 Delock Adapter USB 2.0 Type-A male > 1 x Serial RS-232 DB9 male with screws and nuts ESD protectio…
- it uses FTDI FT232RL chpset and from this PDF (https://www.tme.eu/cz/Document/9d2a0f24d19320b803e2081a185f270d/ft232r.pdf ) it seems to me (I am PC guy, not elec. tech. ) that it should work with TTL (5V) ...
I don't think this 12V/5V thing is the problem. I think TTL levels have always been common for PC serial 'rs-232' com ports.
Test the COM port with a regular device, say, and old modem. Maybe not so simple nowadays.
You could put a bench VOM on the pins that are output, and any DC power source for those that are input (hm, maybe). I used to use serial ports to measure slotcar track times and it was all simple stuff. As I recall, some pins are used as a switch (on/off, for IRQ). Get a decent reference and have at it.
You might want to use a known-good serial port on a regular PC and make sure you machine works with that, assuming you haven't already.
Hard to say about the COM port implementation on the motherboards from what info you have shown. The RS-232 specification for COM ports has been around since the early days of PCs. If the motherboards work they they probably conform to the RS-232 spec rather than TTL.
Page 27 of the PDF for the chip used in the USB to COM dongle has this bit of info -> . .... feature an built in voltage converter to convert the +5V (nominal) VCC to the +/- 9 volts required by RS232.
This could explain why the dongle works and the +/- 5V TTL COM port in the NUC does not. The +/- 9V is well within the RS232 specification. There is also the matter of the data bit inversion issue described in the 'sparkfun' link.
The comment by Scott Pearson about true RS232 being more noise resistant is on point. I do not know the specs on your laser unit but I would bet that the RS232 interface on it expects true RS232 signal levels as it would be likely to be used in an industrial (electrically noisy) environment.
I would risk the few dollars it would take to order one of the RS232 <-> TTL boards from the 'sparkfun' link and give it a try if you don't want to breadboard a test circuit.
So, my dear Intel ... We figured it out ... and I have to say, you totally bungled this
We got to this case again after long time to put some definitive resolution to it.
We tested data pins using Volt meter and again, when using usb-com adapter, data was visible on pin 3 (transfer) - OK (attachment 1 and 1a).
Then we tested using com header and nothing was on Volt meter on pin 3 (attachment 2).
We tried pin 2 (receive): nothing.
Then we tried all options/buttons our software has and one of them was labeled "RTS" (Request to Send) ... When pressed some data was recorded ...
We looked to the tech.doc. (https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/NUC7i3DN_TechProdSpec.pdf ) and under COM header pin description we saw RTS on pin 7 .... ehmmm what??
Immediately we knew we have to try pin 7 ... and indeed data are there
So we "re-pinned" (1..9 > 9..1) original Akasa cable and all is working good.
Question is why Akasa made bad cable ... I once more look at your doc online and there it is pictured ok ... but I remember it was not like that before.
So I found out my doc when we got this problem and ... look at my last attachment "doc-diff"
Original doc (we and Akasa was using that date) was total bulls..t.
So now we feel so frustrated that we have to found this out ourselves and even if we logged this case, NO MENTION here of doc change (= admitting error =resolution).
Have you at least send a notice to your partners who make cables/cases for this NUC (Akasa, ...) ??? If not they are selling non-functional hardware.
Jeez ... we feel like we should get a reward for finding bug (like Google does if someone finds security hole in Chrome).