Beachbum
FabulaTech Forum Newbie
Gender: Posts: 3
|
|
Re: Where to start ?
Reply #3 on: Feb 10th, 2007, 3:09pm |
Quote Modify
|
Good evening Andrew, Sorry for the lateness of my response to your question... 'why could the data be corrupt...' In answer : to date we use a UHF comms link. There are probably a thousand reasons as to why the data arrives at its destination corrupt. Most common of which is someone else is using a similar frequency or producing a 'dirty' or high powered harmonic of their frequency which manifests itself on 'our' frequency and results in sporadic changes in character data or total loss of all or part of a data 'sentence', noty to mention range issues and local mechanical induced RF noise also. It is NOT corrupt as it leave the transmitter (Data Logger) but becomes corrupt during transmission / reception... For whatever reason, the data leaves the Data Logger perfectly and with a known CRC/Checksum that is then extracted and compared to the checksum calculated at the receiver end upon reception. The two (in an ideal world with no corruption) would be the same, however, in reality there are occasions when they differ. The data is then flagged as 'dirty' and dealt with accordingly. With regards to a TCP/IP connection, we (to be fair) don't often find the data's corrupt but rather missing in part or total with TCP/IP or UDP. Total loss is an acceptable risk and relatively easy to deal with. Partial loss is harder to deal with. Either way the CRC/Checksum data checks catches these errors and enables the receiver software to deal with the issue (re-request the data, dump the data, try to extract as much as possible etc...) Having said all the above, how the data becomes corupt is rather immaterial. The fact remains we HAVE to check for data validity BEFORE attempting to use it... and this is why I'd prefer to use a serial to network to serial solution... FYI : The F-T kit / code (DLL/ocx) will only be required at the Control Centre PC - not at the Data Logger (firmware). QUESTION : If I begin to use the downloaded trial of Serial Port Redirector do I only get 15 days or is this negotiable? The reaason for my Q is that 15 days is not a long time for us integrate your solution well enough into our solution for us to trail UNFORTUNATELY, WE CAN'T ALWAYS DEVOTE AS MUCH TIME TO THIS AS I'D IDEALLY LIKE AND, THEREFORE, OFTEN (AT LEAST UNTIL WE'RE FAMILIAR WITH THE KIT) WILL ONLY BE ABLE TO SPEND LIMITED TIME ON ADAILY BASIS ON THIS ASPECT OF OUR SOLUTION... I hope you understand. QUESTION : Do we also need a cable (serial / DB9 female plug to RJ45 socket)? Do we / can we make this (not a problem for us if we know the pin-out) or do you include one? I ask this because, how can we test the solution without interfacing our existing serial port to the web ? QUESTION : OEM License. How does this work please and how much ? Typically I foresee us using just a couple of instances of your solution this year but snowballing to a hundred or so next year and then onwards and upwards (as they say) as we phase out the UHF transmission hardware... Thanks in advance Andrew. Much obliged. If I could call you this would (at this stage) be MUCH quicker and simpler for us - just to get started ? Either way, Thanks and speak soon.
|