Any updates on the development work for t4win?
New release coming soon?
New release coming soon?
T4Win Updates?
- Thread starter blantonl
- Start date
- Status
No, not really ... lots of mostly long overdue fixes that have been in the queue for a few months now.
I do have a thorny issue with Motorola decoding ... getting the decoder to figure out - on the fly - whether the system is VHF/UHF or not. It's a chicken-and-the-egg type problem where the decoder can't do it's job well until it knows which type of system it's monitoring but to make that determination requires it to start decoding.
I've gotten lots of good feedback, support, and code improvements from so many sources ... just need to find some time to tie a ribbon on to the whole package. Of course, as soon as that's done, work begins anew on LTR, MPT1327, and P25 support.
Lindsay ... any word on the RR.com database supporting XML up/down-loading for programs like T4Win ??
-rick
I do have a thorny issue with Motorola decoding ... getting the decoder to figure out - on the fly - whether the system is VHF/UHF or not. It's a chicken-and-the-egg type problem where the decoder can't do it's job well until it knows which type of system it's monitoring but to make that determination requires it to start decoding.
I've gotten lots of good feedback, support, and code improvements from so many sources ... just need to find some time to tie a ribbon on to the whole package. Of course, as soon as that's done, work begins anew on LTR, MPT1327, and P25 support.
Lindsay ... any word on the RR.com database supporting XML up/down-loading for programs like T4Win ??
-rick
rfmobile said:
I am as we speaking getting ready to kick off a project. However, it will be download only, and probably be SOAP based. I'm writing the initial standard and getting the mappings in place from the database to markup tags.
I'll post a request for comments soon - it will probably be very similiar to the Amazon Web services project that was rolled out a few years ago.
I've comitted to releasing a standard, and the web service, sometime this summer. My intention is to have the software developers write to the standard, and let the best software developer reap the rewards.
-Lb
Hello,
When I added VHF/UHF detection to the DOS version of Trunker I realized that I needed to tread lightly or I may break stuff big time. I did crack a few things on the first couple of attempts. I did testing on 800 and 900 MHz systems as well as VHF/UHF before letting it loose and warned that something may be broken. So far it seems to work.
There is alot of knowledge in that old DOS code and it can be difficult to reimplement it. I assume that for type 2 and later revisions the Motorola engineers used reserved codes or previously invalid code combinations for new functions. You are never sure when you are reverse engineering the data stream. I noticed that DOS Trunker takes a conservative approach to decoding OSWs. Maybe too conservative. For example I suspect that some codes that do not map to valid frequencies on a 800 MHz system are also invalid for a VHF/UHF frequency. Unfortunely unless you have direct information about it or can test the code on every 3600 baud Motorola system out there, it is difficult to know. I also seem to remember a few system configuration restrictions that Motorola said not to do on Type 1 systems but a few systems still broke the rules! I thought I was going out on the limb (maybe the jury is still out) when I decided to do the automatic input code detection. I did it because it appeared that a certain osw pattern always indicated a VHF/UHF group call and I was tired of matching input frequencies with outputs. I still put the input frequencies in the sys file so someone can override them. It only does the automatic detection if no input frequency code is present for an output frequency.
One method I can suggest for the windows version is to have a brief time period on startup where it decodes the stream and figures out what type of system it is. I noticed that the DOS trunker version does this via several methods. If it does not see certain OSWs in a certain timeframe it marks it as a old type 1 system.
One thing that is missing for development are log files of various systems that caused problems with a problem description. Also log files of typical types of systems and various functions. If you had a program that can playback log files you can make changes to the decoder and then 'playback' the logs and see if everything still works. When I was on 'vacation' fixing the DOS trunker program in various hotel rooms I did create some logs of motorola systems. No program for playing them back yet.
73 Eric
When I added VHF/UHF detection to the DOS version of Trunker I realized that I needed to tread lightly or I may break stuff big time. I did crack a few things on the first couple of attempts. I did testing on 800 and 900 MHz systems as well as VHF/UHF before letting it loose and warned that something may be broken. So far it seems to work.
There is alot of knowledge in that old DOS code and it can be difficult to reimplement it. I assume that for type 2 and later revisions the Motorola engineers used reserved codes or previously invalid code combinations for new functions. You are never sure when you are reverse engineering the data stream. I noticed that DOS Trunker takes a conservative approach to decoding OSWs. Maybe too conservative. For example I suspect that some codes that do not map to valid frequencies on a 800 MHz system are also invalid for a VHF/UHF frequency. Unfortunely unless you have direct information about it or can test the code on every 3600 baud Motorola system out there, it is difficult to know. I also seem to remember a few system configuration restrictions that Motorola said not to do on Type 1 systems but a few systems still broke the rules! I thought I was going out on the limb (maybe the jury is still out) when I decided to do the automatic input code detection. I did it because it appeared that a certain osw pattern always indicated a VHF/UHF group call and I was tired of matching input frequencies with outputs. I still put the input frequencies in the sys file so someone can override them. It only does the automatic detection if no input frequency code is present for an output frequency.
One method I can suggest for the windows version is to have a brief time period on startup where it decodes the stream and figures out what type of system it is. I noticed that the DOS trunker version does this via several methods. If it does not see certain OSWs in a certain timeframe it marks it as a old type 1 system.
One thing that is missing for development are log files of various systems that caused problems with a problem description. Also log files of typical types of systems and various functions. If you had a program that can playback log files you can make changes to the decoder and then 'playback' the logs and see if everything still works. When I was on 'vacation' fixing the DOS trunker program in various hotel rooms I did create some logs of motorola systems. No program for playing them back yet.
73 Eric
D
DaveNF2G
Guest
delay while analyzing
I've found that when I start up any Trunker (DOS) version on a system with several conversations in progress, the program is easily confused by all of the activity. It usually gets the correct SysID right away, but bogus frequencies, talkgroups, and RIDs get logged before it sorts out what is going on.
The problem occurs least often on Moto Type II systems and most often on EDACS and LTR. It probably has to do with the fact that EDACS and LTR SysIDs have a different meaning and/or the use of LCNs instead of direct frequency mapping.
I think I'd rather see a pause for system identification and analysis before any logged data starts showing up, but on a new and unknown system it could be hard to tell whether a lengthy delay is due to system activity or some configuration error at my end.
I've found that when I start up any Trunker (DOS) version on a system with several conversations in progress, the program is easily confused by all of the activity. It usually gets the correct SysID right away, but bogus frequencies, talkgroups, and RIDs get logged before it sorts out what is going on.
The problem occurs least often on Moto Type II systems and most often on EDACS and LTR. It probably has to do with the fact that EDACS and LTR SysIDs have a different meaning and/or the use of LCNs instead of direct frequency mapping.
I think I'd rather see a pause for system identification and analysis before any logged data starts showing up, but on a new and unknown system it could be hard to tell whether a lengthy delay is due to system activity or some configuration error at my end.
EricCottrell said:
Wayne has had good success with that for Treport by logging and re-playing the datagrams to/from a file.
For regression testing, I use a simpler approach of decoding from a WAV file. When making changes, I can compare the output to previous versions to verify that nothing was broken. A few features have been safely added by using recordings of systems from different parts of the world. The OmniLink site alias feature was verified this way.
-rick
Okay, it's been a bit now.....same question. How's it looking for an updated version?
Whether the system is V/UHF or not...
This won't apply to ALL V/UHF systems but I'd recommend going off the SmartZone current site configuration announcement since it tells you whether the site is Freq Defined, 800, or 900.
For single site/Simo V/UHF networks there's no real way outside of sampling enough group calls and using that as the basis. You'll need to sample enough so stray OSWs don't get combined. I'd say if you see all four of the call grant's OSWs you can safely say the network is V/UHF. Outside of that there is NO way to determine for a non-SmartZone system, not even with AMSS either.
-Wayne
This won't apply to ALL V/UHF systems but I'd recommend going off the SmartZone current site configuration announcement since it tells you whether the site is Freq Defined, 800, or 900.
For single site/Simo V/UHF networks there's no real way outside of sampling enough group calls and using that as the basis. You'll need to sample enough so stray OSWs don't get combined. I'd say if you see all four of the call grant's OSWs you can safely say the network is V/UHF. Outside of that there is NO way to determine for a non-SmartZone system, not even with AMSS either.
-Wayne
The reason this hasn't been done is mostly due to a lack of time to try out different tweaks. I was hoping that I could cheat and let T4Win prompt the user when a new sysid is seen. In theory, if the user tells us the control channel frequency, then we know if it is 800, 900 or something else. In practice, this hasn't performed as well as I had hoped.
This was also supposed to be my silver bullet for differentiating multiple EDACS systems but that's another story.
(In the meantime I've got to pay the bills and feed the kids.)
My P25 activity should be cooling down shortly (for a short spell at least) so maybe I can get back to some old Motorola and EDACS issues that have been haunting T4Win for some 7 months now.
-rick
This was also supposed to be my silver bullet for differentiating multiple EDACS systems but that's another story.
(In the meantime I've got to pay the bills and feed the kids.)
My P25 activity should be cooling down shortly (for a short spell at least) so maybe I can get back to some old Motorola and EDACS issues that have been haunting T4Win for some 7 months now.
-rick
- Status
Similar threads
