Page 1 of 1

Monitoring data flow between Cumulus and an Instromet logger

Posted: Sat 25 Jul 2015 9:09 am
by Hobbyist
I, like a few others, am having occasional problems with Cumulus and my Instromet logger.

Like a recent forum member I have had 'faulty' boards which have been returned to the manufacturer for replacement and at the time seemed to correct the problem but subsequently my slow/none transfer of data returned.

This morning I had to restart my PC due to a Windows 7 update and so far it has taken 1.75 hours to DOWNLOAD data and is still going.

I bought a Maplin unit as an experimental platform it takes approximately 7 seconds but obviously it has not got the same number of records that the Instromet has.

I recently left for a weeks holiday and after I left it seems my logger stopped sending data and I have lost a weeks data for no logical, to me, reason.

My question to the Guru's on this site is - Can I monitor what is actually happening on my USB link between the Logger and the PC without spending a fortune on software/hardware?

It would be interesting to see what data is being exchanged as a possible way forward in this problem.

Thank you for any advice.

Dave

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 9:34 am
by steve
The protocol is actually serial - the USB adapter driver installs a virtual serial port - so that makes monitoring the traffic much easier in theory. But I'm not up to date with what serial port sniffers work with recent versions of Windows, particularly if it's 64-bit.

Can you confirm that you're using the build 1100 of Cumulus that I produced? If you zip up the diags folder and attach it, I'll take a look.

Edit: I found the previous thread where you had tried build 1100, and despite that version not using the 'regress logs' command which Instromet have now asked me to stop using, you still had this problem. I can't see anything wrong with what Cumulus is doing. Is there a way to reset the logger? I'm wondering if previous use of the 'regress logs' command could have put the logger into a strange state where it is no longer functioning correctly.

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 10:15 am
by Hobbyist
Many thanks once again Steve and yes I can confirm that after your last recommendation I did indeed load version 1100.

I wanted to try and sort this query out by looking at the data flow as I am highly suspicious of the logger I/O rather than the Software.

The 'crash' was on the 13th of July which as you can see has produced a large 006 file!

Any pointers are, as always, appreciated.

Dave

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 10:20 am
by steve
Sorry, I started editing my reply while you were offline, but you may have missed my edit:

I found the previous thread where you had tried build 1100, and despite that version not using the 'regress logs' command which Instromet have now asked me to stop using, you still had this problem. I can't see anything wrong with what Cumulus is doing. Is there a way to reset the logger? I'm wondering if previous use of the 'regress logs' command could have put the logger into a strange state where it is no longer functioning correctly.

I do agree that a log of the serial traffic would be useful, if only to present to Instromet as evidence.

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 10:21 am
by Hobbyist
The file did not upload due to it being 46MB in size.

Sorry Steve

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 10:26 am
by steve
I suspect it would just show the same as the previous logs I looked at.

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 10:32 am
by Hobbyist
Interesting suggestion Steve as I have been looking at but failing to find a way to reset the Data store to a reset/zero state.

If I can't do it by looking at data sheets for the chip I will try and sound out Instromet on a method that is practical without damaging the rest of the board.

I have, out of interest copied the last part of the HUGE 006 file and it looked like this.

-----------------------------------------------------------
13/07/2015 19:41:59.080 : next=564 wind=5.6 tot=3716.90185546875 num=667 avg=5.57256650924683
13/07/2015 19:41:59.978 : next=565 wind=3.6 tot=3719.20190429688 num=667 avg=5.57601499557495
13/07/2015 19:42:00.438 : 13/07/2015 18:42:00 elevation=10.749884814174 erv=1.01656480964462
13/07/2015 19:42:00.439 : AddRecentDataEntry: RecentData: Cannot perform this operation on a closed dataset
13/07/2015 19:42:00.878 : next=566 wind=4.5 tot=3717.90185546875 num=667 avg=5.57406568527222
13/07/2015 19:42:01.778 : next=567 wind=4.5 tot=3715.20190429688 num=667 avg=5.57001781463623
13/07/2015 19:42:02.678 : next=568 wind=4.3 tot=3712.60205078125 num=667 avg=5.56612014770508
13/07/2015 19:42:03.578 : next=569 wind=3.1 tot=3710.60205078125 num=667 avg=5.56312131881714
13/07/2015 19:42:04.478 : next=570 wind=2.0 tot=3705.001953125 num=667 avg=5.55472564697266
13/07/2015 19:42:05.378 : next=571 wind=2.9 tot=3702.3017578125 num=667 avg=5.55067729949951
13/07/2015 19:42:06.279 : next=572 wind=3.1 tot=3698.501953125 num=667 avg=5.54498052597046
13/07/2015 19:42:07.179 : next=573 wind=4.5 tot=3694.30200195313 num=667 avg=5.53868389129639
13/07/2015 19:42:08.079 : next=574 wind=2.7 tot=3691.001953125 num=667 avg=5.53373622894287
13/07/2015 19:42:08.979 : next=575 wind=2.2 tot=3682.501953125 num=667 avg=5.52099227905273
13/07/2015 19:42:09.879 : next=576 wind=3.4 tot=3679.40185546875 num=667 avg=5.51634454727173
13/07/2015 19:42:10.780 : next=577 wind=3.6 tot=3679.20190429688 num=667 avg=5.51604461669922
13/07/2015 19:42:11.679 : next=578 wind=5.1 tot=3680.501953125 num=667 avg=5.51799392700195
13/07/2015 19:42:12.579 : next=579 wind=16.8 tot=3691.90209960938 num=667 avg=5.53508567810059
13/07/2015 19:42:13.480 : next=580 wind=13.4 tot=3701.501953125 num=667 avg=5.54947805404663
13/07/2015 19:42:14.379 : next=581 wind=9.6 tot=3706.60205078125 num=667 avg=5.55712461471558
13/07/2015 19:42:15.279 : next=582 wind=6.3 tot=3706.40209960938 num=667 avg=5.55682468414307
13/07/2015 19:42:16.180 : next=583 wind=6.0 tot=3703.90209960938 num=667 avg=5.55307674407959
13/07/2015 19:42:17.081 : next=584 wind=3.1 tot=3698.50219726563 num=667 avg=5.54498100280762
13/07/2015 19:42:17.982 : next=585 wind=2.0 tot=3692.7021484375 num=667 avg=5.53628492355347
13/07/2015 19:42:18.879 : next=586 wind=1.3 tot=3685.50219726563 num=667 avg=5.52549076080322
13/07/2015 19:42:19.779 : next=587 wind=8.5 tot=3681.90209960938 num=667 avg=5.52009296417236
13/07/2015 19:42:20.679 : next=588 wind=4.9 tot=3680.80200195313 num=667 avg=5.51844358444214
13/07/2015 19:42:21.579 : next=589 wind=3.4 tot=3676.80200195313 num=667 avg=5.51244688034058
13/07/2015 19:42:22.482 : next=590 wind=2.9 tot=3675.20190429688 num=667 avg=5.51004791259766
13/07/2015 19:42:23.383 : next=591 wind=3.8 tot=3675.40185546875 num=667 avg=5.51034784317017
13/07/2015 19:42:24.279 : next=592 wind=4.3 tot=3676.60180664063 num=667 avg=5.51214647293091
13/07/2015 19:42:25.179 : next=593 wind=3.4 tot=3678.20166015625 num=667 avg=5.51454544067383
13/07/2015 19:42:26.097 : next=594 wind=1.8 tot=3678.90161132813 num=667 avg=5.51559448242188
13/07/2015 19:42:26.997 : next=595 wind=2.0 tot=3679.80151367188 num=667 avg=5.51694393157959
13/07/2015 19:42:27.897 : next=596 wind=1.8 tot=3680.50146484375 num=667 avg=5.51799297332764
13/07/2015 19:42:28.814 : next=597 wind=2.0 tot=3672.4013671875 num=667 avg=5.50584936141968
13/07/2015 19:42:29.714 : next=598 wind=2.2 tot=3666.50122070313 num=667 avg=5.49700355529785
13/07/2015 19:42:30.614 : next=599 wind=2.7 tot=3661.10107421875 num=667 avg=5.48890733718872
13/07/2015 19:42:31.514 : next=600 wind=2.5 tot=3655.30102539063 num=667 avg=5.48021125793457
13/07/2015 19:42:32.414 : next=601 wind=1.8 tot=3648.80102539063 num=667 avg=5.47046613693237
13/07/2015 19:42:33.314 : next=602 wind=3.6 tot=3647.00122070313 num=667 avg=5.4677677154541
13/07/2015 19:42:34.214 : next=603 wind=3.8 tot=3645.701171875 num=667 avg=5.46581888198853
#HLParsing(Out of memory)with:()

-------------------------------------------------------------

Not sure what the out of memory warning referred to.

I will keep tinkering.

Thanks again.

Re: Monitoring data flow between Cumulus and an Instromet lo

Posted: Sat 25 Jul 2015 11:17 am
by steve
I think the 'out of memory' is from the diags logging component due to the size of the log.