RE: [timexdatalinkusbdevelop] Re: Help with USB comm app
- View Source
Wayne, good input. And yes, lots of us are reading and following people’s emails. I jump in every so often. I am hoping that when the various data elements are fed into the watch that the extra space is eliminated as much as possible. At least, that is what the Timex tech support fellow told me was the case for the Contact database. Since I worked with mainframe computers most of my professional career, I am use to database systems frequently using up unnecessary space, and the Timex Contact data format has a lot of slots for data I don’t want to carry around. I would be interested to see what you find if you check out that database. I don’t know how much memory the watch has, but I don’t want to waste any of it on empty slots.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Wayne Venables
Sent: Saturday, March 20, 2010 2:13 AM
Subject: RE: [timexdatalinkusbdevelop] Re: Help with USB comm app
Thanks for the reply – I was beginning to think that nobody was reading this list anymore. I figured it out and it’s something that isn’t documented. The PC software pads every database by a constant size. So even though the Neolink database fits in 64 bytes, it actually allocates 1280 bytes for it. This is true of every database – it adds 1216 bytes to all of them. Presumably this means that databases can grow by that amount before needing a complete rewrite of all the watch data. For maximum compatibility I’ll be providing the same padding.
I didn’t know about libdlusb – I’m impressed it’s still being updated. It might be helpful as an extra reference for all the different database formats.
The app (and libraries) are written in C# -- so technically it’s Windows-only. However, code exists for Mono that provides a HID interface in Linux so porting it to Linux using Mono should be pretty straight forward. I’m using SQLite for data storage which is also cross-platform.
The one thing I won’t be doing in this software is replicating the existing PC DLL interface. It’s just too messed up of a design. The problem you describe with the databases is exactly the thing I want to avoid. But this means all 3rd party wrist app PC interfaces will have to be recoded for this software. I’m thinking rather than call DLLs, I would spawn a child process and pass in the database over stdin and retrieve the updated database from stdout (as well as some control data). It should make the PC interfaces easier to build (in a multitude of languages) and easier to port to other platforms.
The project has been fun (and surprisingly successful) so far. Still a long way to go though – every single built in mode needs an interface.
Sorry for the slow reply; I've been so busy lately. I don't know where all the time goes.
I'm not an expert by any means on this (far from it, in fact), but I can give a try at helping. Answers below. If you do make progress, please let us know what you find, so we have a record of it.
> I'm working on a bit of a hobby project to replace the current desktopsoftware with something a bit more modern. I have the low-level USD HID interface completed as well as the higher-level TUCP protocol. I'm at the stage of reading and writing data to the watch and now working on exactly how to write the applications and databases.
Awesome! I look forward to seeing/using it. Out of curiosity, what platform is it going to be for? Cross-platform would be awesome (hint, hint). I'm assuming you know about libdlusb:
http://geni. ath.cx/libdlusb. html
though I'm not sure exactly how useful it will be.
> In addition to using the documentation to guide me, I used a tool tocapture all the USB communication between the Timex software and the watch. I then wrote a script to interpret that information as TUCP commands to make it easier to follow.
Nice idea. I'll point out that in my experience, most of the Timex documentation needs to be taken with a spoonful (not just a grain) of salt. It's often unclear, and sometimes just plain wrong. For example, I was working on reading the database file that comes from the watch, for my own purposes. The docs say you should look in the DB folder at upwristapp#. bin. While this does contain the info, it's not really the one you want, since if you modify that, the old data will still be sent back to the watch. Instead, you want to use the files in the Data folder WristappDB## .bin, where # and ## are actually different from each other (one is the mode in the watch, the other is the "instance" in the PIM software). But I digress.
> I'm still trying to figure out exactly how it all works -- I was expectingthat the app code and data offsets would be written somewhere by the PC software but instead it appears that everything is written linearly (code from one end, data from the other) and the offsets are calculated internally by the watch using the sizes of the data. The problem I'm having is that the sizes of the data sent by the PC don't seem to correspond to what I think they should be.
Of course not. That would be too easy, and clearly the documentation can't be entirely accurate. :)
> For example, this is AppInitExternal command for Neolink (the first app Ihave installed):
I'm unfamiliar with that command. I tried looking through some of the docs, for reference, and I found many from tucp.dll, but not that one. Where is it from? It's not from the PIM sourcecode, either.
> AppInitExternalthat is all PC software writes:
> Size: 28
> 01 00 00 00 00 00 00 00 00 40 19 24 00 00 05 06 e3 00 00 00
> 00 00 7b f3 1a f3 00 00
> 0x1940 is the code size
> 0x0024 is the heap size (36)
> 0x0500 is supposed to be the database size (right?)
> However, the database size for Neolink is only 44 bytes (64 allocated) and
So I now probably have a different version of Neolink from the one you're using (also because I uploaded a patch last week), so it's a little difficult for me to tell. The 0x0500 is definitely not the database size, since as you say that should be 44 for Neolink (a little more, now, but a minor point). Perhaps they do a similar trick for databases as in the database header, and just specify the multiple of 64, somewhere?
A quick look at that sequence makes me think it's related to the _par_018.bin file, especially since that e3 looks suspicious to me - I know that's the AppType number I specified for Neolink.
> But I don't see where that number is being communicated to the watch. Someof the values for the other applications for the database size seem right, but it's harder to tell. I feel like I'm missing something here, but I'm not quite sure exactly what.
Yes, I remember looking in one of the files once (tucp.ini, I think) and being similarly perplexed that things didn't seem to add up right. But it does work, so it must be right somewhere. Perhaps your assumption that the next position is the database isn't correct?
> If anyone who's an expert is still lurking around here, I hope you canhelp!
As I mentioned, I only know bits and pieces. This is mostly uncharted territory. It's fun to be a trailblazer, but it can be frustrating, too. Don't forget to leave some breadcrumbs behind for the rest of us to follow!
- View Sourcetonsofquestions wrote:
>[...]The company I work for has signed a deal with one of the largest
> Also, has anyone done work on porting the VDLK to Lazarus, since I
> updated sourceforge? I don't have time to do much right now, and I'm
> really not very familiar with Pascal. I'm more of a "make modifications"
> kind of guy here.
companies in Portugal and I am right in the middle of that storm. This
is a major opportunity for my company but according to the latest
forecasts the storm will last until late July... :(
I'm still hoping that I'll be able to try to port VDLK to Lazarus as a
weekend project, one of these weekends, but my spare time, as usual, is
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
"Every drive dies; not every drive really lives."
-- Braveheart meets 21st century technology. :^)