Not at all. As I said, RThreshold = 1 assures that an OnComm event will be generated for the single byte.
However, if many bytes are received (for arguments sake, let's say 50 bytes, back to back at 9600 bps), one or more OnComm events will be generated. At a guess, I'd say there will be about three or four events generated for these 50 bytes.
OK Dick. Roger that.
<--- Did someone help you? Please rate their post. The little green squares make us feel really smart!
If topic has been resolved, please pull down the Thread Tools & mark it Resolved.
Is VB consuming your life, and is that a bad thing??
Has anybody got a link to the manual for this thing? All I could find was a rather useless brochure. I have dealt with many data loggers quite a bit over the years and they are very easy to use but this thread is really confusing me. How can this be so hard?
Now I cannot be much use with the coding because I have always used C++. Borland to make matters worse but there is nothing to stop you using Windows reading from a datalogger unless we have some really weird piece of equipment here.
Slower than a crippled Vista
More buggy than a fresh XP install
Look! Down the road, some 50 miles behind the drunken snail.
It's Ubuntu!
Dick summarized the overall operation of comm well. Seems the main problem lies on the fact that windows is multitasking and if any other task lasts long it is possible to face with overruns, so it is not a good idea to decrease the length of receive buffer.
I saw that there are two conditions for receive event to be fired.
1 - USART buffer is full (interrupt), for default case 14 bytes are received,
2 - At timer tick (interrupt) system detects that there are some bytes in buffer that is greater or equal to RTreshold.
This way it is possible to have receive event even if only 1 byte is present, but delay depends on system clock (up to 15ms). It means if you are dealing with large number of bytes in a single frame (especially at high speeds) then you won't have any trouble getting receive event every time buffer is full. This explains the results of my tests under such circumstances, I received several events within one tick period and fetch the data successfully.
It comes to a more interesting point. While designing a system communicating half duplex, if the slave sends data exactly equal to the buffer size then you get maximum speed. While trying to receive a few bytes will last up to 30ms, receiving 14 bytes will last only 1.5ms . This is a useful analysis for me, thanks to all.
Looking at some different comm port properties, yes, I saw that their buffer sizes may vary. While the system port on mb has 14 byte buffer, my add-on card is capable of buffering 28 bytes. It is possible to adjust it from control panel. Is there a way of changing setting from vb (even Dick said it is not implemented) ? We can use DLPortIO to access hardware if it is permitted. Changing the buffer size we can set it to the expected number of bytes and get receive event exactly on time.
AsmIsCool, unfortunately I couldn't be able to find a document which explains all details and tricks of comm port operation. What you can do is arrange your own from the forum messages, if you can prepare such a document and share it would be great
Mars base one Username: Jim Davis Password: yCrm33
Posts
1,284
Re: Receiving data from serial port
kiymik: "depends on system clock (up to 15ms)." there no such system clock running at 15 msec...
only vb timer is limited as hell, but the winmm timer (that is used by almost every component) is running at 1msec precision. the delay you are experienced is could be because of the DPC latency, that is 20-50 uSec on good pc's, and might can go up to 1000 uSec (that is 1msec) on damned vista, and bad driver combos.
Virtually there is. May be also physically there is.
Try this code :
HTML Code:
Private Sub Timer1_Timer()
If List1.ListCount > 100 Then Exit Sub
List1.AddItem Str(List1.ListCount) & " " & Timer
End Sub
Set timer interval 1ms and see that events are spaced with 15.6ms. Set timer interval 20ms and see it is 31.2ms. For every computer I got the same precision, that caused me to think that vb is doing periodic jobs in 15.6ms intervals (may be it is not actually system clock). Checking incoming serial data is one of these jobs.
Mars base one Username: Jim Davis Password: yCrm33
Posts
1,284
Re: Receiving data from serial port
Nope, that is would be a limitation of vb timer. I also provided here an example showing a comparison of vb's timer control and winmm timer. There you can see that the vb.timer is inaccurate (even on lower timings) it also shown that theres 'nothing' under 15msec. but winmm timer can go down as 1msec. so 'physically' theres no such timer. but virtually is.
the thing is, vb.timer have different purpose. vbtimer is running on low resources, and optimized for daily usage, but not for precision. for that purpose, you have to use the windows multimedia timer, or queryperformancecounter api.
Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution
It can be used for shorter timings as well (as the test results shown also on my previous experiment, i got it to be stable on 1 msec timings).
Jim, for precise timing it is better to use winmm timer it is obvious. I didn't have time to test it yet, I don't expect any problem anyway. But since vb itself is not using it in conjunction with comm it doesn't help comm receive event detection. Thank you for the links, they are useful.
The microcontroller is running 2-50MIPS ????,
the microcontroller get a Byte (looks up the Byte), then sends That Byte at 9600 bps,
If there is other tasks for microcontroller to complete such as to receive sensor data, the microcontroller will go to receive the data first,
then resume, get a Byte(looks up the Byte), then sends That Byte at 9600 bps.
So on .......................................
Ok!
Your box is???? 1Gb???, 2Gb???, 3Gb???
May-be Windows is not able to keep up with the microcontroller,
May-be it is able.
Important!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
You'll not know if you don't "give it a go".
I'm not a scientist nor engineer, and I've written no books
I'm not a, the glass is half full person.
I'm not a, the glass is half empty person.
I'm not a, the glass is twice as big as it needs to be person.
-----------------------------------------------------------------
I'm a, We got half a glass, now let's do some thing with it, person.
I classify myself as a "give it a go", person
By Lee Black 27/Oct/2009
Mars base one Username: Jim Davis Password: yCrm33
Posts
1,284
Re: Receiving data from serial port
Originally Posted by kiymik
Another note : sleep() also has 15.6ms resolution
That ain't true. Unstalbe? Yes. But the resolution is 1 mSec. The stability issues goes between 0-1 mSec. That might be an issue, but still, it doesnt 15.6 msec. Where do you get your informations?
I've just put together this measurement app. Let's see what do you get.
If you add Jim's test Project to a MSComm Project,
set InputLen = 1, and count the time OnComm event, then you'll know the time you have in the OnComm event.
Has anybody got a link to the manual for this thing? All I could find was a rather useless brochure. I have dealt with many data loggers quite a bit over the years and they are very easy to use but this thread is really confusing me. How can this be so hard?
Now I cannot be much use with the coding because I have always used C++. Borland to make matters worse but there is nothing to stop you using Windows reading from a datalogger unless we have some really weird piece of equipment here.
AsmIscool You can find the protocol in EndlessNameless post
Originally Posted by EndlessNameless
Well. One of my main problems is I am still learning. My ultimate goal is to read the incoming data and display it to graphs and gauges. A typical weather program. Making my own weather software has been a long time goal of mine as far as programming. So far I have programmed a voice operated light control console using a basic stamp, vbasic6 and various voice activation programs such as e-Speaking (nice piece of software for the price). Now my next step is this weather station.
I have found the protocol to my weather station here - http://www.netsky.org/WMR/Protocol.htm - so I know what the data structure is. I've been puzzling this over for months now and working on it here and there.
Basically I know generally how it is done, but am running into snags with fine details (as is so often the case). I've tried using the split, mid and left functions, but they don't seem to be working so well with integers. I tend to get a lot of out of range errors when using these functions to put data into arrays. Am I wrong in thinking they are made for text strings? Forgive the dumb questions, but as I've said I'm still fairly new to everything.
Yes Jim, your code shows sleep is fast. Attached is my test program, when I ran it at home I also got a lot shorter sleep values, may be because of some overhead it resulted with 1 to 2ms difference (setting 1ms got 2ms delay, setting 10ms got 11.7ms etc.). With the same code I got 15ms on my business computer (even if it is faster than my home computer). But.... at the time I tested it there was about 20 windows opened, spreadsheets, communication programs, browsers, mails, some u-controller development software and so and so. Any time this program sleeps windows was dealing with the others that may extend sleep time virtually.
This means if more precise timing is desired than no other application must be running. Also, using QueryPerformanceCounter together with sleep() will improve accuracy.
But we are talking about 9600 baud here. PC CPU is running at around 2GHz. UART can more than handle it if you allocate a reasonable buffer. Every single datalogger I have worked on requires you to send a request. You tell it which channel and it sends the data. There are no variable length packets because you know what you asked for. I really need the manual and not a summary if I am to have a hope of understanding this. Is this thing just spitting out data arbitrarily.
Slower than a crippled Vista
More buggy than a fresh XP install
Look! Down the road, some 50 miles behind the drunken snail.
It's Ubuntu!
My understanding of this datalogger, is it has a buffer so if there is other tasks for it to do it can stop and do the task or tasks, then resume at the next Byte or chunk of Bytes.
There for,
it gets one Byte or one chunk of Bytes from the buffer (looks up the Byte or chunk of Bytes) ¨[this takes MIPS], then resumes,
sends That Byte or chunk at 9600 bps.
Maybe it will be a variable length chunk of the packet.
Mars base one Username: Jim Davis Password: yCrm33
Posts
1,284
Re: Receiving data from serial port
@AsmIscool dont worry i've already put together an interpreter that could be modified to work with this stuff. i just dont understand why 11 ppl downloaded but no one put a single feedback is it working or not. well, maybe not; but it's hard to say without real test cases.