Announcement

Collapse
No announcement yet.

I'm very angry & disappointed !

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • I'm very angry & disappointed !

    Hi All,
    I just write to tell you my bad experience with the uDrive :
    My idea was to make a continous numeric camera with a uCAM JPEG.
    But now I give up !!!! That's enough !

    1/ I confirm that the 4D datasheet is incomplete & false (when writing FAT file there is NO ACK after each packet, but just at the begin and at the end).

    2/ There is no timing precision (what is the minimum write time ???) .
    Even after 4 or 5 new files created without any errors , the 6 new file is KO, and the uDrive is out !.
    The module DOESN'T work in total reliability at 115200 or 256kbaud without a 10mSec tempo after each packet of 32 bytes...

    3/ So I made an automatic reset system wich work very well. In 99% of times when a NAK comes, the uDrive is resetted and work again (with 1 second late, not very good for a camera).
    But even with this, the UDrive is KO after 256 o
    r 512 or may be 333 new files.
    There is always a problem.
    After 2 weeks of hard work, I give up.
    I've read all forums, I've all tried, my source code is 'bulletproof'
    my time-outs very long, and the result is always the same.

    I can write 511 files, and the 512 is KO .....! The FAT is limited to 512 files ????

    I give up.

    Bye

  • #2


    Interesting first post

    1) There is indeed ACKs after each block, use FAT Controller and check 'log all data' you will see the ACKs flowing

    2) What do you mean by timing precision? The write time is pretty much based on the speed of the uSD card you use, and where it is in the current cluster, the cluster size and other things related to FAT. As for Baud rate, uDrive will communicate at any speed you can get it to Autobaud to, you can send megabytes at 256kbaud, no problems. Actually I reckon you should be able to talk to it at 600kbaud.

    3) Why on earth would you need to reset the uDrive?

    Can't work out what you are getting at with the file limit, it's whatever you format the root folder of the uSD card to format (512 is the default). I you searched the forum you would have found how to fit thousands of files in the root folder.

    Why didn't you ask for help earlier?

    Why aren't you asking for help know?

    Please try the above and if you can't get anywhere post some of your code and we'll try and help
    Mark

    Comment


    • #3


      Hi, thanks for your answer,

      1) There is indeed ACKs after each block, use FAT Controller and check 'log all data' you will see the ACKs flowing

      -> When i've read this http://4d.websitetoolbox.com/post?id=4948954&goto=nextnewest , I understood that there is just ACK at the beginning and at the end of file.... And yes, it's better.

      2) What do you mean by timing precision? The write time is pretty much based on the speed of the uSD card you use, and where it is in the current cluster, the cluster size and other things related to FAT. As for Baud rate, uDrive will communicate at any speed you can get it to Autobaud to, you can send megabytes at 256kbaud, no problems. Actually I reckon you should be able to talk to it at 600kbaud.

      -> Why talk to 600kbaud when you must wait 8mSec after each packet of bytes ? I need +/- 3 seconds to store 10ko. This could be fine with 19200bauds ! And as soon I try to remove tempos the NAKs come back after just one file.
      My SDCard works very fine with faster video rates in a mini Camcorder.

      3) Why on earth would you need to reset the uDrive?

      -> After a maximum of 4-5 files of 10ko, the NAKs are back. A 0ko false file is created, and the only solution is to reset and overwrite.

      Can't work out what you are getting at with the file limit, it's whatever you format the root folder of the uSD card to format (512 is the default). I you searched the forum you would have found how to fit thousands of files in the root folder.

      -> I've just searched again all uDrive/usbDrive forums and found nothing!

      Why didn't you ask for help earlier?

      -> I prefer to be sure of my code, and made hundreds of tests before sending this post.
      I hope this uDrive is not used in military, medical, or other difficult applications !!!!

      Thanks....

      (p.s: we just speak here about uDrive, but there is a lot to say about the uCAM JPEG , and its strange reactions).

      Comment


      • #4


        Why talk to 600kbaud when you must wait 8mSec after each packet of bytes ? I need +/- 3 seconds to store 10ko. This could be fine with 19200bauds ! And as soon I try to remove tempos the NAKs come back after just one file.

        If you have a requirement for a high data throughput you should be writing in RAW mode, sector by sector and reading the card back into a file http://4d.websitetoolbox.com/post?id=4865971

        My SDCard works very fine with faster video rates in a mini Camcorder.

        Your mini camcorder probably accesses the card in SD mode rather than SPI mode (a 4x speed improvement) and probably also has specific hardware to write to the card that makes it faster again.

        I've just searched again all uDrive/usbDrive forums and found nothing!
        http://4d.websitetoolbox.com/post?id=3202192 scroll down to the mkdosfs reference


        I hope this uDrive is not used in military, medical, or other difficult applications !!!!
        It is indeed and we have several letters of appreciation from medical users

        Please, get the uDrive running with FAT Controller, as well as the way it shows you the protocol, it also has a tests tab, which, by default, creates and reads 20 FAT files using Different handshaking techniques. The test I just ran at 256kbaud with handshaking of 50 gave an average throughput of 110kbaud Write and 94kbaud Reading a 215kbyte file. (timings subject to the vaguaries of my PC)


        (p.s: we just speak here about uDrive, but there is a lot to say about the uCAM JPEG , and its strange reactions).
        Indeed that is a strange beast. Unfortunately it is based on the 'industry standard' OV528 and/or OV529 chips, we have no control over the imbedded software. We have added the 'quirks' to the documentation and produced software that demonstates how to get it to work. We would love to produce our own 'Quirk free' software from scratch, but simply do not have the time.
        Mark

        Comment


        • #5


          Hi !
          I've FOUND SOMETHING intersting !
          The first ACK comes after 32 bytes, even with a 50 bytes package lenght !
          That was my case, and my controler didn't like this (It's more logical to wait a datas ACK when all the datas are gone).
          I work now with 32 bytes package lenght, and that's ok.
          No more extra tempos are required, but the 512 entries limitation convinced me to use the RAW mode.
          My post was certainely too severe and I apologize.
          Your datasheets are just a bit 'minimal'...

          p.s : My uCAM work fine now at 115200bauds, but after three hundreds tests it's impossible to get an entire picture at 230400bds...

          Regards

          Comment


          • #6


            32 as hex is 50

            Is something confused somewhere?
            Mark

            Comment


            • #7


              Hi !
              Why are you complicating things ?

              I just say when you SEND 50 BYTES WITH A 50 BYTES PACKAGE LENGHT (5*10 = 50) you receive an ACK approximately at the same time as the 32 th byte (32 = 30 +2 in decimal human numbering).
              This could be a problem with non buffered application like mine.
              Bye.

              Comment


              • #8


                Why are you complicating things ?
                Sorry, just shooting in the dark to see if I could help in a round about way

                This could be a problem with non buffered application like mine.
                Oh dear, finally the penny drops (for silly me)

                That second ACK you are getting is coming immediately after the first ACK and is 'by design'.

                Here's an excerpt from a forum post in May 2009

                The quick answer is that uDrive assumes that if you specify a packet size greater than 1 that your host can also receive that many bytes at a time.
                So it sends a double ACK at the start to help keep things moving, by enabling each ACK to be encoded / transmitted / decoded at the same time as packets are moving in the other direction. This increases the overall data transfer speed quite a bit.
                The poster at the time was happy with that explanation and went away and coded around it. However, changes were made to the PmmC to add an option to disable this DOUBLE ACK at the start of transmission.

                This altered PmmC has never been released. I can email it to you if you'd like, but it needs the manual to be changed before it can be put on the website.

                Sorry again, for the confusion this would have caused you
                Mark

                Comment

                Working...
                X