Change the duty cycle of the serial port ?

Question

1.00/5 (1 vote)

See more:

Hello, i want to change the duty cycle of my serial port com when it sending data !! is there a commande line that change the duty cycle of the port com ??

here is a picture of a data that i sent: View image: 9a52d018 2af2 496b 8503 fa17fd7d20b5[^]
i want the duty cycle to be at 70% thanks.

thanks

Posted 14-May-16 12:52pm

Jammes_Ca

Updated 14-May-16 21:04pm

Patrice T

v3

Add a Solution

Comments

Sergey Alexandrovich Kryukov 14-May-16 20:04pm

What is that, "duty cycle"? :-)
Anyway, the question makes no sense at all.
And there is nothing which would require any command-line set-ups of the port.
—SA

George Jonsson 14-May-16 20:15pm

You need to elaborate a bit more.
How do you use the serial port?
Which pin are you measuring on?
How do you generate the current pulse train?

For regular serial communication you have different baud rates and you cannot really control the duty cycle. (Well you can send certain byte combinations, perhaps)
If you are using DTR and/or RTS and control them via code, you can change the duty cycle.

So you see, your question doesn't contain enough info to give you an answer.
If you show some relevant code, there is someone in the forum that can help you solve the problem.

And no, there is no command line tool, unless you write it yourself.

Jammes_Ca 15-May-16 4:18am

Hi, thanks for your answer, my code is verry sample i send data with standard serial port communication. here it is
<pre>#include
#include
#include

#define RX_SIZE 4096
#define TX_SIZE 4096
#define MAX_WAIT_READ 1

HANDLE g_hCOM = NULL;

COMMTIMEOUTS g_cto =
{
MAX_WAIT_READ, /* ReadIntervalTimeOut */
0, /* ReadTotalTimeOutMultiplier */
MAX_WAIT_READ, /* ReadTotalTimeOutConstant */
0, /* WriteTotalTimeOutMultiplier */
0 /* WriteTotalTimeOutConstant */
};

DCB g_dcb =
{
sizeof(DCB), /* DCBlength */
9600, /* BaudRate */
TRUE, /* fBinary */
FALSE, /* fParity */
FALSE, /* fOutxCtsFlow */
FALSE, /* fOutxDsrFlow */
DTR_CONTROL_ENABLE, /* fDtrControl */
FALSE, /* fDsrSensitivity */
FALSE, /* fTXContinueOnXoff */
FALSE, /* fOutX 4 */
FALSE, /* fInX */
FALSE, /* fErrorChar */
FALSE, /* fNull */
DTR_CONTROL_DISABLE ,/* fRtsControl */
FALSE, /* fAbortOnError */
0, /* fDummy2 */
0, /* wReserved */
0x1000, /* XonLim */
0x1000, /* XoffLim */
8, /* ByteSize */
NOPARITY, /* Parity */
TWOSTOPBITS , /* StopBits */
0x11, /* XonChar */
0x13, /* XoffChar */
'?', /* ErrorChar */
0x1A, /* EofChar */
0x10 /* EvtChar */
}
BOOL OpenCOM (int nId);
BOOL CloseCOM ();
BOOL ReadCOM (void* buffer, int nBytesToRead, int* pBytesRead);
BOOL WriteCOM (void* buffer, int nBytesToWrite, int* pBytesWritten);

int main()
{
unsigned char buffer[250]={85};// 85 = 01010101 binary

WriteCOM(buffer+c, 1, &nBytesWritten);

//
//

//
}
// other function
</pre>

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2016-05-14T21:04:00

Solution 1

If those are individual bit traces you are looking at : 10101010 then basically, no - you can't: serial data bits are always nominally symmetric - and the pattern would be hard to repeat continuously unless you are really careful with data, start and stop bits and parity, and have some mechanism to keep the IO port loaded with data.
If you want to use USB as a PWM...then you could probably do it by sending data that has a series of '1' followed by a shorted series of '0's, no parity and fine tuning the stop bits (you have the choice of 1, 1.5, or 2, so you have a little margin here) - but...the PWM frequency would drop to about 1/8th of the nominal TX frequency (so 9600 baud would give you a pulse frequency of around 120Hz) and you would be subject to hardware related frequency differences (serial IO is specified as within 10% of the nominal speed, which is why you need both stop and start bits on each character).
And you'd still have to keep the buffer fully loaded.
Plus, serial IO signals aren't meant as driver signals: there really isn't a lot of power behind them.

I'd use "real" hardware: it's going to be easier, and a lot more reliable!

Posted 14-May-16 21:04pm

OriginalGriff

Comments

George Jonsson 15-May-16 4:10am

I guess you mean 'RS232 as a PWM', not 'USB as PWM'.
+5 for the good explanation.

Jammes_Ca 15-May-16 4:19am

Hi, thanks for your answer, my code is verry sample i send data with standard serial port communication. here it is
<pre>#include
#include
#include

#define RX_SIZE 4096
#define TX_SIZE 4096
#define MAX_WAIT_READ 1

HANDLE g_hCOM = NULL;

COMMTIMEOUTS g_cto =
{
MAX_WAIT_READ, /* ReadIntervalTimeOut */
0, /* ReadTotalTimeOutMultiplier */
MAX_WAIT_READ, /* ReadTotalTimeOutConstant */
0, /* WriteTotalTimeOutMultiplier */
0 /* WriteTotalTimeOutConstant */
};

DCB g_dcb =
{
sizeof(DCB), /* DCBlength */
9600, /* BaudRate */
TRUE, /* fBinary */
FALSE, /* fParity */
FALSE, /* fOutxCtsFlow */
FALSE, /* fOutxDsrFlow */
DTR_CONTROL_ENABLE, /* fDtrControl */
FALSE, /* fDsrSensitivity */
FALSE, /* fTXContinueOnXoff */
FALSE, /* fOutX 4 */
FALSE, /* fInX */
FALSE, /* fErrorChar */
FALSE, /* fNull */
DTR_CONTROL_DISABLE ,/* fRtsControl */
FALSE, /* fAbortOnError */
0, /* fDummy2 */
0, /* wReserved */
0x1000, /* XonLim */
0x1000, /* XoffLim */
8, /* ByteSize */
NOPARITY, /* Parity */
TWOSTOPBITS , /* StopBits */
0x11, /* XonChar */
0x13, /* XoffChar */
'?', /* ErrorChar */
0x1A, /* EofChar */
0x10 /* EvtChar */
}
BOOL OpenCOM (int nId);
BOOL CloseCOM ();
BOOL ReadCOM (void* buffer, int nBytesToRead, int* pBytesRead);
BOOL WriteCOM (void* buffer, int nBytesToWrite, int* pBytesWritten);

int main()
{
unsigned char buffer[250]={85};// 85 = 01010101 binary

WriteCOM(buffer+c, 1, &nBytesWritten);

//
//

//
}
// other function
</pre>

OriginalGriff 15-May-16 4:31am

But...a standard serial port is not just the data bits: it's a start bit, the database and in your case two stop bits: so sending each character as 01010101b means
0 - start bit
10101010 - data bits, LSB first
11 - 2 stop bits.
And there is no way to force a serial port to create an asymmetric data bit so zeros are shorter than ones - because it relies on "time slicing" the data pin to determine if a bit is a zero or a one when it reads, and asymmetric data would not slice well, and would give bad data.
Seriously, find a better way! This is not a good idea...

Jammes_Ca 15-May-16 4:47am

ok but you know, i send this data with IR led, i have an IR led that connected to a com port, my other problem is how to change the frequency of the PCM modulation ?? i want 135 Khz, how do i to change the pcm modulation ??

OriginalGriff 15-May-16 4:59am

Don't.
First off, the PWM won't be accurate (and you'd need a faster-than-standard serial port to get anywhere near 135KHz as the BAUD parameter specifies bits per second, so 9600 baud is 9600 Hz at best.
Secondly, driving an LED directly from a serial port data line is a recipe for dead hardware - you can do it in some cases, but it's generally a poor idea as the port doesn't drive or sink much current and it's nominally a +12VDC to -12VDC swing for '0' and '1'.

You want to use "proper" hardware for that - you can't faff with serial ports, they won't do what you want.

Jammes_Ca 15-May-16 5:13am

i will sho you something, in this picture http://postimg.org/image/oy3eqsh69/

it's a data sent by a "pda called mx workabout over an IR connected to TTL"

and this picture http://postimg.org/image/elsuuh5v5/
the same data that i sent with an other "pda called PIDION BIB600"

so how do you explain that the duty cycle for those 2 pda is not the same why ??

maybe due to to the TTL ???

OriginalGriff 15-May-16 5:39am

Better driver chips would be my guess.
But the first image looks like oversampling and a false trace to me - but without your scope in front of me I can't say.

Jammes_Ca 15-May-16 8:14am

the two images is a data sent throught an IR, the data is a letter "U"

the first image is a data sent by an mx workabout it has aTTL connected to an IR component
and the seconde picture is a PIDION who has an IR builtin.

and we see the leeter U int the oscilo
U = 01010101 in binary