Author Topic: EEVBlog 121GW Discussion thread  (Read 776631 times)

0 Members and 1 Guest are viewing this topic.

Offline Seppy

  • Supporter
  • ****
  • Posts: 189
  • Country: au
  • Curious
Re: EEVBlog 121GW Discussion thread
« Reply #400 on: March 16, 2018, 03:46:55 am »
Are you on windows or Android, which version of the app?

I tried Android Version 0 eevblog.x121gw, but my perl script displays the same values.

It doesn't matter, fix the BT transmission with a correct buffering implementation.

I understand the Perl script might be receiving the wrong thing too. Just to be thorough can you check if the updated android app resolves your issue.
Curiously the android app store might not have received the latest updates... Checking into this now... Ok it should be version 1 now :)
« Last Edit: March 16, 2018, 03:54:46 am by Seppy »
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: EEVBlog 121GW Discussion thread
« Reply #401 on: March 16, 2018, 11:53:31 am »
I understand the Perl script might be receiving the wrong thing too. Just to be thorough can you check if the updated android app resolves your issue.
Curiously the android app store might not have received the latest updates... Checking into this now... Ok it should be version 1 now :)

Thanks.

I tried with version 1, it's still as broken as version 0.

Could you push your changes to github?

I'm more interested in receiving the data on my desktop, I use the phone just for checking.
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: EEVBlog 121GW Discussion thread
« Reply #402 on: March 16, 2018, 12:53:32 pm »
The errors on the main display are also still there if you leave it running a bit longer:

Quote
1521202937.913 2017-08 00042    Power DC (VA)  1409.7 mVA       DCA  255.34
1521202938.183 2017-08 00042    Power DC (VA)  140.97 VA        DCA  255.34
1521202938.858 2017-08 00042    Power DC (VA)  1409.7 mVA       DCA  255.34
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #403 on: March 16, 2018, 01:37:24 pm »
What process is UEi and Dave following for firmware releases?

I do not know what procedures or processes UEi use.
As for this firmware release, UEi said they fixed the issues with the VA mode data corruption on Bluetooth, so we checked that and it seemed to be fixed, so I released the firmware on here so other could try it.
David has a setup that is sniffing the microcontroller UART data and comparing with received Bluetooth data. We could see the data corruption clearly before the fix and after the fix it's gone. It was reasonable to conclude they had fixed it, so pushed it out for others to confirm. We didn't test anything else on this release.

At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback. Would current owner prefer we not make interim firmware releases available for testing?
 
The following users thanked this post: 1anX

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: EEVBlog 121GW Discussion thread
« Reply #404 on: March 16, 2018, 02:03:48 pm »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.

This is fine, but please "fix" things and don't "cover up".

The bluetooth transmission is broken by design and by implementation.
  • There is no data integrity, aka. CRC or something on records (design error)
  • The ASCII decimal/hex coding wastes more then 2/3 of the already scarce bluetooth bandwidth (design error)
  • You have to check every single byte received for plausibility (and you'll fail in a lot of cases) (implementation error)
  • If you look at the errors in the data it's clear that some buffer in the firmware get's overwritten (implementation error)

Would current owner prefer we not make interim firmware releases available for testing?

I'm fine with testing, no problem.

But the 1.07 -> 1.09 is not a fix, it's just trying to cover up above mentioned errors a bit better.

Start with fixing the missing CRC. Then errors can be detected reliably and automatically and one can trust the data received is what the firmware wanted to send.
 
The following users thanked this post: 1anX

Offline 1anX

  • Regular Contributor
  • *
  • Posts: 195
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #405 on: March 16, 2018, 10:06:04 pm »
What process is UEi and Dave following for firmware releases?
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback. Would current owner prefer we not make interim firmware releases available for testing?

Thanks Dave!

My concern was that in your previous post you stated that the new firmware release fixed the BT data corruption issues. You maybe could have said please test this new release which addresses the BT data corruption issue and provide feedback if any issue remains.

I know it seems pedantic but when you claim that the issue is fixed, we actually believe the issue is fixed!

I worked in a metrology lab for a few years and that required me to be pedantic. Near enough is not good enough  :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #406 on: March 16, 2018, 10:31:29 pm »
My concern was that in your previous post you stated that the new firmware release fixed the BT data corruption issues. You maybe could have said please test this new release which addresses the BT data corruption issue and provide feedback if any issue remains.

Yes, I should have said that, sorry.
From our end it did look like the data corruption UART issue we reported had been fixed, and that seems to be the case.
I know some people are still reporting bluetooth data corruption issues, and this seems to be a different issue than the one we had UEi adress, which was corrupted data output from the UART in the micro.
Please take every release at this stage to mean "we believe it's fixed, please test it and let us know if you find any issues".
 
The following users thanked this post: 1anX

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #407 on: March 17, 2018, 02:29:06 am »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.
This is understandable - and very effective - but there will be some who will get their nose out of joint because everything isn't perfect ... including the software revisions.  To those I say this: When a car maker designs and builds a new car, they don't just dump the first models straight from the factory to the showroom.  It goes through a proving ground where issues are identified and dealt with.  For the 121GW - we are that proving ground and we are still in the stage of finding and fixing issues.

From our end it did look like the data corruption UART issue we reported had been fixed, and that seems to be the case.
I know some people are still reporting bluetooth data corruption issues, and this seems to be a different issue than the one we had UEi adress, which was corrupted data output from the UART in the micro.
This is a good example where different problems can have similar looking symptoms - and that the fixing of one problem may not result in a total cure.  For a complete solution, each and every problem needs to be individually identified and addressed.  Where it is stated that one particular problem has been fixed, don't immediately assume the symptoms you have observed should go away and that if they don't, that you are being misled.

Quote
Please take every release at this stage to mean "we believe it's fixed, please test it and let us know if you find any issues".
This.
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11709
  • Country: us
Re: EEVBlog 121GW Discussion thread
« Reply #408 on: March 17, 2018, 03:10:22 am »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.
This is understandable - and very effective - but there will be some who will get their nose out of joint because everything isn't perfect ... including the software revisions.  To those I say this: When a car maker designs and builds a new car, they don't just dump the first models straight from the factory to the showroom.  It goes through a proving ground where issues are identified and dealt with.  For the 121GW - we are that proving ground and we are still in the stage of finding and fixing issues.
It was not clear to me that people purchasing the meter were expected to be Beta tester's until I had heard Dave mention it during an AmpHour.   I'm sure he must have stated this upfront and I just missed it.   As long as it was made clear, I don't see a problem.  On the other hand, if it wasn't and people were trusting that Dave would not allow it to be sold as a Beta, then maybe that's a problem.  Seems like most in the USA are still waiting, so no concerns other than not meeting their scheduled dates. 
 
The following users thanked this post: 3db

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #409 on: March 17, 2018, 03:56:42 am »
I must admit that I cannot recall Dave making such a statement (I don't listen to many Amphour episodes) - but it was just my natural expectation for a brand new product having non trivial features.

To me, it is essentially the same as when a new operating system is released.  However much it has been tested and stressed, there are always some issues that show up when a broader user base gets involved.

For the 121GW, I saw this as normal.


(IMO, Dave's best move was getting that micro SD card slot included.  Without that, firmware updates would have been a lot harder for some people.)
 

Offline dcac

  • Frequent Contributor
  • **
  • Posts: 339
Re: EEVBlog 121GW Discussion thread
« Reply #410 on: March 17, 2018, 03:07:34 pm »
I don’t think anyone is surprised that there was issues still needing to be fixed - but for me beta-testing is a contract you “sign-up” for and really not anything I would “buy into”. Dave never ever used a term like beta-testing in his promotion of the 121GW and I really do not envy those backers who got semi-hassled into it. Also it’s (not) funny with those who are not backers at all having much opinions on what to expect and what not to expect. I’m a JB Goode backer my self but are no longer particularly keen on getting my 121GW delivered, if I now say it’s because I know there will still be issues needing to be fixed - I’m sure the none-backers will tell me - to not be so pessimistic.
 

Offline 1anX

  • Regular Contributor
  • *
  • Posts: 195
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #411 on: March 17, 2018, 10:23:11 pm »
A one sentence summary would be that the 121GW meter was a good idea poorly implemented!

Hindsight is a wonderful thing, but maybe if Dave ponied up and backed his own idea and design instead of a freebie UEi deal, it may have actually been developed and tested before being released to backers to buy?

The potential for getting a useful meter, (I'm Johnny Be Goode backer) is still high, but the way it has been handled with bugs and switch problems has certainly knocked the gloss of acquiring this meter for me!
 
The following users thanked this post: 3db, ChrisG

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #412 on: March 19, 2018, 12:02:16 am »
I am not sure why he chose to use the open forums for discussions and bug reporting versus the locked down kick start area.  Maybe he has more control over the content here. 

Kickstarter comments sucks as a place to hold discussion from a technical and usability point of view, but yes, I could have done that and "kept it quiet", but this forum is just a better place to do it, so here it is. If I wanted to "have control" then this whole thread wouldn't even exist, let alone be set as sticky.
But maybe I should have kept it on Kickstarter as those people are the ones vested in it?  :-//
 
The following users thanked this post: ChrisG

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #413 on: March 19, 2018, 12:13:37 am »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.
This is understandable - and very effective - but there will be some who will get their nose out of joint because everything isn't perfect ... including the software revisions.  To those I say this: When a car maker designs and builds a new car, they don't just dump the first models straight from the factory to the showroom.  It goes through a proving ground where issues are identified and dealt with.  For the 121GW - we are that proving ground and we are still in the stage of finding and fixing issues.

We didn't want that to be the case of course, but we've been essentially forced into this situation with the unexpected problems that have popped up.
And by "forced into" I mean it's basically the best way forward at this point for all involved.
The best way to get issues found is by having as many people as possible use the meter and provide feedback as possible. Given that we have like 200 or something meters out there in the field now, it just makes sense to at least ask these owners to try new firmware and continue to provide feedback before we ship 2000 of them. They don't have to of course, they can stick with the firmware they have got.
But ultimately any new firmware on a reasonably complex product like this is going to have issues that will take time to sort out.

BTW, David in his testing has found a couple of more unreported issues that are currently being looked into, hence more delays unfortunately.
 

Offline The Soulman

  • Frequent Contributor
  • **
  • Posts: 949
  • Country: nl
  • The sky is the limit!
Re: EEVBlog 121GW Discussion thread
« Reply #414 on: March 19, 2018, 12:24:58 am »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.
This is understandable - and very effective - but there will be some who will get their nose out of joint because everything isn't perfect ... including the software revisions.  To those I say this: When a car maker designs and builds a new car, they don't just dump the first models straight from the factory to the showroom.  It goes through a proving ground where issues are identified and dealt with.  For the 121GW - we are that proving ground and we are still in the stage of finding and fixing issues.

We didn't want that to be the case of course, but we've been essentially forced into this situation with the unexpected problems that have popped up.
And by "forced into" I mean it's basically the best way forward at this point for all involved.
The best way to get issues found is by having as many people as possible use the meter and provide feedback as possible. Given that we have like 200 or something meters out there in the field now, it just makes sense to at least ask these owners to try new firmware and continue to provide feedback before we ship 2000 of them. They don't have to of course, they can stick with the firmware they have got.
But ultimately any new firmware on a reasonably complex product like this is going to have issues that will take time to sort out.

BTW, David in his testing has found a couple of more unreported issues that are currently being looked into, hence more delays unfortunately.

Those 2000 get the updated hardware (switch..) right?
What about the meters stuck at the harbor, are these unstuck yet?
What about selling these to "qualified" (those that are aware of what they are getting themselves into) beta testers?
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #415 on: March 19, 2018, 09:18:09 am »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.
This is understandable - and very effective - but there will be some who will get their nose out of joint because everything isn't perfect ... including the software revisions.  To those I say this: When a car maker designs and builds a new car, they don't just dump the first models straight from the factory to the showroom.  It goes through a proving ground where issues are identified and dealt with.  For the 121GW - we are that proving ground and we are still in the stage of finding and fixing issues.

We didn't want that to be the case of course, but we've been essentially forced into this situation with the unexpected problems that have popped up.
And by "forced into" I mean it's basically the best way forward at this point for all involved.

I have no doubt at all you didn't want to have to be in this position - but it seems fairly clear that the testing phase has been poorly executed.  Where that fell short will be a lesson for future benefit.  For now, the best effort is in sorting it out.

I will say that if the 121GW had hit the deck with no significant issues, I would have been truly impressed - but the number of issues detailed so far has been a bit of a surprise.  What I expected to be a bit of "fine tuning" has turned into a significant exercise.  I think Dave would have had a similar expectation.


There is no question, however, that the way forward has been defined by the situation.
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #416 on: March 19, 2018, 09:55:51 am »
A one sentence summary would be that the 121GW meter was a good idea poorly implemented!
I understand where you are coming from, but I would call that a bit harsh.  I would call that a "consumer" comment, not an "engineer" one.

Quote
Hindsight is a wonderful thing, but maybe if Dave ponied up and backed his own idea and design instead of a freebie UEi deal, it may have actually been developed and tested before being released to backers to buy?
There are a lot of factors in producing any item and I sincerely doubt Dave would have been able to bring this product to life without UEI's contribution.  Certainly, there has been an issue with the testing and that is the only criticism I have - but Dave probably didn't do himself any favours by having the development so highly visible.  The interest and yearning from so many members no doubt added a lot of pressure to get the product out.

Quote
The potential for getting a useful meter, (I'm Johnny Be Goode backer) is still high, but the way it has been handled with bugs and switch problems has certainly knocked the gloss of acquiring this meter for me!
I am quite the opposite.  Having seen the effort being put in, I am becoming more engaged.  The gloss is increasing!
 
The following users thanked this post: geekGee

Offline IanB

  • Super Contributor
  • ***
  • Posts: 11859
  • Country: us
Re: EEVBlog 121GW Discussion thread
« Reply #417 on: March 19, 2018, 10:08:41 am »
I will say that if the 121GW had hit the deck with no significant issues, I would have been truly impressed - but the number of issues detailed so far has been a bit of a surprise.  What I expected to be a bit of "fine tuning" has turned into a significant exercise.  I think Dave would have had a similar expectation.

This is, IHMO, a sign of the times and an indication of the state of business and commerce today. Costs are being driven down, work is being outsourced, complicated tasks are being assigned to the young and inexperienced.

As far as the 121GW is concerned, I bet the hardware has far fewer issues than the software. It's because software design is not recognized as challenging problem requiring deep expertise, and software then gets written by "coders" instead of engineers. The word "coding" should be removed from the dictionary.

I am sure we have all experienced web sites and phone apps that are simply buggy, broken and unpredictable in use. It's all symptomatic of the same general trend.

 
The following users thanked this post: 1anX

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #418 on: March 19, 2018, 10:31:09 am »
As far as the 121GW is concerned, I bet the hardware has far fewer issues than the software. It's because software design is not recognized as challenging problem requiring deep expertise, and software then gets written by "coders" instead of engineers. The word "coding" should be removed from the dictionary.

The 121GW has an extra layer complexity in the chipset, which has crazy amounts of configurability and modes etc. UEi had to recently go to Hycontech to ask their advice on some things for example.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #419 on: March 19, 2018, 10:32:58 am »
Dave probably didn't do himself any favours by having the development so highly visible. 

Yep, I'm not very smart  :palm:
 
The following users thanked this post: SeanB, chefkoch84

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37730
  • Country: au
    • EEVblog
Re: EEVBlog 121GW Discussion thread
« Reply #420 on: March 19, 2018, 10:34:51 am »
Those 2000 get the updated hardware (switch..) right?
[\quote]

Yes.

Quote
What about the meters stuck at the harbor, are these unstuck yet?

Yep, all finally unstuck.

Quote
What about selling these to "qualified" (those that are aware of what they are getting themselves into) beta testers?

I'd rather not, we already have enough keen people out there testing I think.
 
The following users thanked this post: The Soulman

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #421 on: March 19, 2018, 11:53:53 am »
Dave probably didn't do himself any favours by having the development so highly visible. 

Yep, I'm not very smart  :palm:

I wouldn't say that.  Doing the 121GW was an exciting project.  Sharing it was mandatory!

What I will say is that, having been a member of the 121GW Voyeurs Club, I have a much greater "connection" to the 121GW than I do to any other meter ... and I haven't even ordered one yet!

I don't have a big problem with the issues at hand - just as long as they are addressed.
« Last Edit: March 19, 2018, 11:56:33 am by Brumby »
 
The following users thanked this post: geekGee

Offline Brumby

  • Supporter
  • ****
  • Posts: 12297
  • Country: au
Re: EEVBlog 121GW Discussion thread
« Reply #422 on: March 19, 2018, 12:07:36 pm »
Sure.  Play that card if you must, but even if I did have a 121GW in front of me right now, my answer would be the same.

I have means to make measurement with other gear I have.
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: EEVBlog 121GW Discussion thread
« Reply #423 on: March 19, 2018, 12:26:50 pm »
Well. I don't have an issue with the issues too. But I have a bit of an issue on how the issues are addressed.

Dave and Seppy know about the invalid bluetooth records. They worked around them in their app. But instead of asking UEI to include some checksum or CRC in the records, they decided on guessing if the data could be valid and try to suppress records in the application, that look wrong.

If you use your phone for logging and send yourself the logfile, you can see that also their app fails at guessing always correctly. You mostly don't see it on the phone display, as you don't look constantly at it and miss the occasional wrong value, but it's in the log of the app.

I can understand, that finding the cause of the errors might be hard, but adding a CRC to the records is a no-brainer and around 30 lines of code.

That's the part I don't understand.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVBlog 121GW Discussion thread
« Reply #424 on: March 19, 2018, 12:55:41 pm »
At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.

This is fine, but please "fix" things and don't "cover up".

The bluetooth transmission is broken by design and by implementation.
  • There is no data integrity, aka. CRC or something on records (design error)
  • The ASCII decimal/hex coding wastes more then 2/3 of the already scarce bluetooth bandwidth (design error)
  • You have to check every single byte received for plausibility (and you'll fail in a lot of cases) (implementation error)
  • If you look at the errors in the data it's clear that some buffer in the firmware get's overwritten (implementation error)

Would current owner prefer we not make interim firmware releases available for testing?

I'm fine with testing, no problem.

But the 1.07 -> 1.09 is not a fix, it's just trying to cover up above mentioned errors a bit better.

Start with fixing the missing CRC. Then errors can be detected reliably and automatically and one can trust the data received is what the firmware wanted to send.

No need to implement CRC, because BLE has this already integrated on the lower levels and automatically resends packets, if they are wrong, so no need to implement it on the data layer. Usually you can be sure that the transmitted data is right, so it must be another problem.

I personally tested a Blue Gecko chip from Silicon Labs with BLE and at the application level only the packet rate drops when I increase the distance. Here are some numbers where the device was sending 20 byte packets with max speed, which I recorded with a Python script :

Code: [Select]

measuring in 1 m distance:

number of packets: 348697
transfer time: 255 s
lost packets: 0
average transfer rate: 27310 bytes per second
max delay between two packets: 79.6 ms
min delay between two packets: 0.0 ms

measuring in 7m distance, with 2 walls in between:

number of packets: 265549
transfer time: 331 s
lost packets: 0
average transfer rate: 16044 bytes per second
max delay between two packets: 284.1 ms
min delay between two packets: 0.0 ms

This was with a standard BLE dongle on a PC, which identifies in Linux as this with lsusb:

Code: [Select]
Bus 001 Device 012: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

I implemented the nRF UART protocol on the BLE chip for easier testing, as described here:

https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/how_to_implementuar-ovZ7

Because I really don't like all the complexity of BLE, give me just a reliable UART link, which works for me now. Maybe UEI should hire me to fix their bluetooth implementation :)

Here is the Python script which received the data on the PC:

Code: [Select]
import struct
from bluepy.btle import *

# callback class
class MyDelegate(DefaultDelegate):
    def __init__(self):
        DefaultDelegate.__init__(self)

    def handleNotification(self, cHandle, data):
        print(data)

# connect to device
per = Peripheral("00:0B:57:1D:B3:93", "public")

try:
    # set callback for notifications
    per.setDelegate(MyDelegate())

    # enable notification
    setup_data = b"\x01\x00"
    notify = per.getCharacteristics(uuid='6e400003-b5a3-f393-e0a9-e50e24dcca9e')[0]
    notify_handle = notify.getHandle() + 1
    per.writeCharacteristic(notify_handle, setup_data, withResponse=True)
   
    # send test string
    c = per.getCharacteristics(uuid='6e400002-b5a3-f393-e0a9-e50e24dcca9e')[0]
    c.write("Hello Gecko")
   
    # wait for answer
    while True:
        if per.waitForNotifications(1.0):
            continue
finally:
    per.disconnect()

And here is the Python script which evaluated the received data to create the statistics:

Code: [Select]
#!/usr/bin/python

import sys

filename = sys.argv[1]

# statistic variables
count = 0
lastPacketNumber = 0
lastTimestamp = 0
deltaSum = 0
maxDelta = 0
minDelta = 1e9
packetsLost = 0
absoluteTimestamp = 0

# read file and calculate statistics
with open(filename, "r") as ins:
    for line in ins:
        values = line.split(";")
        packetNumber = int(values[0])
        timestamp = int(values[1])
        delta = timestamp - lastTimestamp
        if count > 0:
            if timestamp < lastTimestamp:
                delta = 32768 - lastTimestamp + timestamp
            if delta > maxDelta:
                maxDelta = delta
            if delta < minDelta:
                minDelta = delta
            absoluteTimestamp = absoluteTimestamp + delta
            if packetNumber - lastPacketNumber > 1:
                packetsLost = packetsLost + packetNumber - lastPacketNumber - 1
        lastPacketNumber = packetNumber
        lastTimestamp = timestamp
        count = count + 1

# format milliseconds with suffix and one digit after the comma
def formatMs(ms):
    return "{:.1f} ms".format(ms)

# convert ticks to seconds   
def ticksToS(tick):
    return float(tick) / 32768.0

# convert ticks to miliiseconds
def ticksToMs(tick):
    return ticksToS(tick) * 1000.0

# calculate some more statistics
transferTimeInSeconds = ticksToS(absoluteTimestamp)
bytesTransfered = count * 20
bytesPerSecond = float(bytesTransfered) / transferTimeInSeconds

# show result
print("number of packets: %d" % (count))
print("transfer time: %d s" % (int(transferTimeInSeconds)))
print("lost packets: %d" % (packetsLost))
print("average transfer rate: %d bytes per second" % (int(bytesPerSecond)))
print("max delay between two packets: " + formatMs(ticksToMs(maxDelta)))
print("min delay between two packets: " + formatMs(ticksToMs(minDelta)))
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf