At this point in the project, I've been idle for a few weeks. I've been doing other things like moving into a new apartment and working. I have cable TV now so I've been watching TV more than usual...but it'll probably taper off after I get used to it. There're many more channels to watch now but still nothing good is on TV most of the time.
The recorder items that I plan to address in the next set of updates are:
- Add the code to make the WAV file usable even after a power failure. Also this will make it possible to listen to the file using a media player while the recording is in progress.
- Finish packaging the future freeware SR Pro (Lite) version and put it up on the web site. I need to create an installer for this program and do some documentation tasks.
- Write the user guide. I've started outlining the guide based on the available dialog boxes in the recorder. I've started filling in some of the details, so far.
I'm thinking about a couple of future ideas for the project:
- I want to completely re-write the player and use a different approach to how the player will work. Right now, the existing player, requires a .log file in order to operate with an SR Pro VOX-mode recording. The current player treats the .WAV file as several binary audio blocks that each have a beginning and end. The player plays each block of audio based on the .LOG record information that is available. So the player basically plays each block in a start-stop manor. When the event # increments during playback, the player is being told to play each segment in a separate way. Now I want to redesign the player to treat the audio as one continuous block of binary audio. Instead of the player playing each segment separately, the player will stream the audio continuously and slave the display clock to the audio stream so that the clock always reflects the original recorded date and time. I hope that made sense. It's a big difference in how it works and it's a better way to handle the two pieces of information, (the audio file and the log file). I am also considering embedding the log information into the .WAV file itself in the future so that the .LOG file is not needed by the player at all.
- As soon as I buy my first trunk tracker receiver, (it'll be Uniden I'm sure), i can start working on getting the frequency logging to work with that brand radio.
Beginning work on the file "checkpoint" facility which will be used to keep the .WAV file up to date in the event of a system outage. It is designed to keep most of the recording session intact if the power suddenly goes off.
I'm currently looking at the compression problem and have found the cause. This problem is the one where VOX recording using certain compressors will result in garbled audio. Until I upload the fix, please avoid using the Mpeg layer 3 and ADPCM CODECs if you want to use VOX. Fortunately, this bug doesn't affect the GSM CODEC.
I am working on the fix for this problem right now (Sunday). I expect a fix in the next few days.
Mpeg Layer 3 problem found. Please read the bug sheet to see the details.
I was wrong about having found and fixed the MPeg3 related VOX problems. I have partially fixed it and now the Mpeg Layer 3 CODEC can be used (again) to make VOX recordings.
But I am still working on this problem with the help of others to make sure I'm doing everything correctly with regard to using the Windows compression facilities.
At this time, I am comfortable with the operation using MPeg Layer 3 as the compression method. But there still seems to be a VOX recording related problem when using the MS ADPCM CODEC. Avoid using MS ADPCM with VOX mode if you want to avoid that problem.
------------------------
Let me say this, in case it bothers people to see me talking about the problems with the recorder instead of the good things, here in this news blog:
Bugs are a fact of life. If any other developer or company tries to tell you that their software has no bugs, then they are naive. Bugs ALWAYS exist in software above a certain level of complexity. I will NEVER try to hide the fact about the existence of any bug from the public. I want you to know what you're getting for your effort and your donation money, before you decide to make the donation....in order to get the pro version.
I am showing a lot of bug activity here in the news lately because I am onto the final trail of an old bug that has been in the recorder for a long time. Compression bugs are critical and require the utmost care in making sure that they are not going to cause any problems. There are different behaviors inside the software for different compressor CODECs. Some work better than others and some don't work at all if you do one little thing wrong. In the upcoming weeks I will be continuing the focus on the compressor to make sure the problems have all finally been fixed.
Incidentally, I haven't heard any bug reports from users related to these compressor issues. Maybe folks have not been using the same CODECs that I have on my machine.
Bottom line: I feel good about using most compressors now (except the MS ADPCM), in VOX mode. But... all of them seem to work fine if VOX mode is not used.
As of Build 0.86, go ahead and use any compressor you want during VOX recordings. But don't use MS ADPCM yet until I get that problem fixed also.
Best wishes
I can't believe I let this blog go on this long without an update.
As of build 90 there is now an installer. Please try it and see if you see anything that needs to be fixed. I don't expect anything, but I only have my XP system to use for testing and this installer has only been tested on XP sp2 so far.
If you click the mouse on the digital clock which is on the main panel, it will show the elapsed recording time from that point on. All instances of SR Pro that are launched after that point will show the elapsed indicator instead of the clock...until the clock is clicked a 2nd time.
I'm gearing up to get the pre-trigger setting in there and then I will be working on the file refresh issue to make it possible to listen to a recording while it is in progress (from the .WAV file). This is a lot of work and I have already started some of the coding necessary.
The next planned update after this is to put resource shortage error recovery into the recorder. Right now, it will fail if you push it too hard on a slow computer trying to compress too much at too high a data rate. Slow computers need to use lower data rate settings for the compression if any buffer counts start to climb too high (see the buffers indicator on the front panel). There is also no code to handle a disk space shortage either.
Adding logging support for some Uniden scanner models that support the GLG or GID (serial) commands. Since more than one new field needs to be added to the log, that means the log has to be reformatted in order to accommodate the extra information.
Preliminarily Supported Models:
BCD396XT
The work on the Uniden and Icom receiver logging support is in progress, but I'm still in the early stages of designing the new interface. Since I just threw in the Icom support without much planning for expandability, the old user dialog and internal code has to be scrapped. The new design (at this time) will allow the user to choose what receiver info to include into the log records. This approach will make it possible to choose a whole variety of information from Uniden radios and perhaps some additional information (in addition to the frequency), from Icom radios.
I'm just getting started with the coding work, so this update could be several weeks minimum to finish. Until I get done adding the Uniden support and new user interfaces, there will be no (other) updates to the recorder in order to complete the work in progress.
I have completely removed all the old Icom radio interface code with the intent of completely rewriting it. In the process of adding the new Uniden radio support, I have decided on a design that allows the user to choose what will be in the log from the radio. In the case of Uniden, there are lots of choices of items that can be included in the log due to the flexible nature of the Uniden serial protocol, compared to the less flexible Icom protocol. My goal is to allow the user to add as many additional fields to the log file as they want.
I'm finally writing some new code and have a solid design that I am working with now. I don't work on the recorder every day, but slowly I'm adding more capability to this thing. At this point, since the design is done, I expect the pace of the work to pick up now.
The web site was just converted from MS Front Page to another format.
All pages have been modified in the process of converting the web site.
If anyone notices any problems, please contact me ASAP via the SR pro email address listed on the SR Pro main page.
A lot of work has been completed on the new radio serial interface. I have been slowily making progress on this new part of the program. Almoist all of the UI work is done, but a lot of work is still left to do.
So far I Have:
- Created a new panel and all the code that is behind the new panel has been tested.
- Defined a new internal architecture to control all the radio I/O operations for the serial port.
- Written most of the code to handle the new model.
I still need to
- Complete the work on the internal operations that handle the actual radio transactions.
- Add code to change the log file format so that the new radio info can be added to the end of each event record. The log file format needs to be changed to handle a variable number of optional fields now. Also the log file format is going to be changed to make it into a CSV file. The new format will make it easier to retrieve a variable number of items during playback. The current log format is too limited to handle the new radio interface model.
- Incorporate the new log file format into the player. This will be after the next recorder build is complete so that the Uniden logging changes will be available to use earlier. No sense in holding up the recorder while the player waits to get finished.
Initially only some Uniden models will work, but after the initial release of the Uniden support is in use, I will add the other models. The problem is that I wasn't aware that there are at least two different protocol standards out there for Uniden radios, when I designed the Uniden serial interface. The standard that I already have incorporated into the recorder handles the command and reply formats of the 396XT, 396T, and other trunking handhelds (AFAIK). The other format that needs to be added later handles older Uniden radios that reply with multiple output lines instead of the consistant CSV like format of the 396's.
The Uniden radio support is slowly (but surely) coming along. I chose the more difficult path in that I could have just added a few fixed fields to the log for certain Uniden models. But instead, I decided to make a more general purpose, versatile and more complex method of adding the radio information to the log.
This is what the current (under construction) radio settings panel looks like (so far).
Screenshot of unfinished Radio Settings panel.
Here's a short explanation of the new logging panel.
There is a radio type tab that is shown here (greyed out and Uniden is selected). When you choose one of the supported radio types (which will be Icom and Uniden initially), the "Cmd Code" tab (below it) will allow you to choose one of several serial commands. In this case, the tab shows that the command "GLG" is being used.
By clicking the button called "Test Cmd", you can see the actual radio output without having to find out during a recording that you configured the settings wrong.
Anyway, the job list in the upper center of the panel has a list of Uniden serial commands. Each command has (what I call) a result index. This is the way you choose which comma delimited item in the reply that you are interested in logging during a recording. As you can see, this job list shows several commands to be issued and each has an index. The result of each of these items in the job list will be added to each line of the log file whenever a new sound is heard by the recorder. This panel is not finished yet. Only the Test Cmd button talks to the radio so far.
I hope this new interface I'm working on isn't too intimidating or confusing. It has a few buttons and there will probably be a few more when I'm done, but in order to allow you to choose your own radio serial fields to use in the log, it's necessary to have a way of choosing the Uniden or Icom replies. Uniden is the only radio supported that has a consistant CSV like output... (Well... some models). That makes this type of interface possible.
------
I wrote the above text a few days ago. Today is Sunday and I haven't done any work to the recorder for a few days. I'm back on it today and this is how it goes. On and off. I go through periods of not doing anything then I go back and continue, just like a weekend carpenter that adds onto their home in little increments. It's never finished but if you stand back and look at it using a time-lapse point of view, you see that major things do happen over time. This Uniden addition is more work than I wanted it to be, but it'll be worth the wait. This will be the ONLY logging recorder that allows the user to choose which Uniden info fields from many types of dynamic info inside the radio. In other words, you can choose to have the TGID, followed by the frequency, followed by the name of the system being scanned, followed by the group name and then the pl tone data, or you can add the radio status line # 3 from the LCD display to the log if you want.....and on and on...I hope you like this approach because it's going to take a but longer than it would've otherwise. Anyway, I'm going to get back to work on the recorder now.
Note: I am not used to writing a journal like this. I should've entered all the new stuff at the top instread of the bottom. Oops...
The latest news on the recorder development is:
The recorder can retrieve all the info from the (Uniden BCD396XT) receiver now in test mode.
I still need to connect the new code to the logging facility to get the new info into the log and this means I need to change the log file format some. This isn't very challenging. I just need to fiddle to make it look lined up and neat so the log doesn't get all jagged on the right when the info from the radio changes.
I realize that some things I do end up seeming like overkill. Maybe the new log retrieval capability for SR Pro is more than is needed and overly complicated for some. I'll have to create some examples to show people how to get the basic info from the radio. I also need to present some information on how the fields of the serial commands' returned responses are organized. Or I might just explain the basics and pass the buck to the user's manual for the scanner. I think I might just do that.
The good news is that the recorder will soon be logging the info from (some of the ) the Uniden radios. The bad news is that the Player will be unable to understand the new log format at first because the format will be different due to the changes I'm making. This is temporary. The thing is, if I were to finish the changes to the player before publishing the updated recorder then people will have to wait longer for Uniden logging support. I choose to release it in two stages: 1st the recorder then the player.
And...I might want to mention that I temporarily took out the Icom radio support until I get done with Uniden. I had to gut the whole way it was being done before and rewrite most of the serial control logic. Now it won't be much work to get Icom added back to it. That's all for now.
SR Pro is now logging from the Uniden 396XT, 396T and others that use the same (single reply line CSV format) serial protocol.
I just got the logging feature working late last night. I will be testing it over the weekend and uploading build 94 most likely during this weekend.
As you probably already know, this will break the player. You should hold onto your old recorder if you want to use the player to listen to the recordings. This will be temporary.
Regarding the player, it is due for some major rework soon. It has a drift problem (by design, unfortunately), that has been decribed in the past and this problem will be eliminated once and for all. It might take a while (just like the Uniden mods did (or is taking...)).
I plan to write some online help docs to help people get started using the recorder and I plan to start with the explanation on how to use the new Uniden info capture mode because it's problably now the single most complex item one has to learn how to use on this recorder.
Here's a look at the first log I ever recorded some Uniden info into.
I uploaded the new build 94 which now supports logging Uniden radios that use a serial connection and support the following serial commands:
GLG, GID, STS, PWR, MDL, VER, VOL, SQL, P25, BAV and WIN
Each Uniden reply from the radio has one or more text fields seperated by a comma. The recorder can take one or more fields from these Uniden command (replies) and put them into the log file. The first 6 radio items are also shown on the front panel.
I wrote a simple utility called UnidenTest that you can download and use to test your serial link. If you use other programs that communicate with the radio through the serial connection then UnidenTest and SR Pro should also work.....(I hope)...
Take a look at the new Radio Settings panel and try to make sense of it. You will need to learn where the various reply items from the radio are, such as the freq. (I believe that is the PWR or WIN commands). The signal strength is located in the reply from the PWR command also. The GLG command has many items you might want to log such as the talk group tag name, group name, system name. The STS command seems to have whatever else you might need and it takes this info from the front panel.
This is something new and no one has tried it yet. I have no documentation yet and I really hope that by uploadeding build 94 now, instead of after I write the how-to's on using the new features, I can make the new recorder available to people, but also not get inundated with emails asking how to use the new stuff.
Please don't email me on how to use the new features. I will provide some help on the web site soon. I want to take a break now and think about the changes that are needed to make the player work with the new recorder.
Here's a small list of changes to build 94:
- Added Uniden radio logging support for models that support STS and other 3-letter commands. Replaced the radio settings panel with the new panel.
- Created a tool called UnidenTest to allow simple serial port testing. If your scanner works with UnidenTest then it should work with SR Pro.
- Fixed scheduler bug caused by missing files.
- Added an option to choose high Q compression, (in audio settings dialog). This allows the user to choose whether to use higher quality compression or lower quality (less CPU) during compression.
- Changed the default VOX value from 0 to 10%.
- Added * on title bar next to the profile name to show when the profile has been changed.
- Modified some of the display refresh rates to improve CPU performance.
- Log data is CSV compatible if you delete the header lines out of the file. You can also copy and past the data into a CSV file. (CSV stands for Comma Seperated Values, I think). CSV files can be imported into MS Excel.
Tips for using the new logging support:
- Make sure you remember to turn on the "Automatic Fetch" button on the Radio Settings panel if you want it to log the Uniden radio info.
- Don't bother trying the 2 Icom commands. They aren't supported yet. This is temporary.
- Test each Uniden command using the Test Cmd button. Then after you see the correct item displayed below, add that command to the job list. That will add that item to the log in the order that they are listed.
- Don't push too much serial data through using too slow a baud rate. And keep the VOX hold time long enough to ensure the COM port transactions all finish before the next VOX event starts.
Added a short guide to show how to use the new logging feature.
I just uploaded the recorder again with a minor change: (I did not change the build number this time) Now the quotes have been removed from the radio logged items.
Folks who want to use the Uniden logging support:
- Only certain radios are supported including 996XT, 996T, 396XT, 396T and other radios that support 3-letter serial commands with CSV output. Careful not to risk unpredictable problems that might happen if you send the wrong command to the wrong radio. Some commands could be mis-interpreted (perhaps, I'm just speculating a worst case scenario), and cause changes in the radio's settings or memory contents or worse. Just make sure your radio supports commands like "STS" or "PWR" or "GID".
- You will most likely need your radio serial control codes and they are in some manuals. I found my radio's codes in the 396XT pdf file.
Build 0.95 is available. It has a new player build that works with the Uniden radio logging support. It looks a little different now. I will soon need to write up some help info on how to use the player. There is a lot more to this build than meets the eye.
There's more to say about this build, but I want to finish up here later. It's Friday evening and I want to put this project down for the night.
Enjoy the new radio logging capability.
Hint: Try using a spread-sheet like Excel to sort the log file records to play them back in a differrent order. This can be very useful. Think about it....
I've decided to add some more Uniden serial commands to the recorder to allow use of more models. I'm currently adding serial commands that should work with the 898T. There are already commands fot the 396XT and others that use those same commands.
Icom support is still availabe in build 0.93. But... I will get the icom stuff back in the new recorder soon. I brought my Icom receiver to my apartment and will be setting it up and connecting it to the computer soon.
Here are the news bits for the project.
- I plan to fix the player drift problem soon with a calibration fix instead of tearing it apart and rewriting parts if it. All it will take to correct the player drift issue is to allow the user to calibrate the player so it won't have any more drift issues. Here's how I plan on implementing it - If you listen to the last few events on the player, that's where the drift problem is always the worst. By measuring how many seconds of error there is (just by manually litening to the audio I guess....for now), one can adjust all events to play from the proper point in the audio file stream. Then you just enter the amount of correction to apply at the end and it will apply the correction to everything in between the beginning and the end.
- Automatic old file deletion is coming soon. It's an easy thing to add. It shouldn't take very long to get it in there.
- I'm considering adding a delay value to the radio query commands that you configure in the radio settings panel. I'm noticed that since the BCD396XT has had the unit ID update, the recorder has trouble grabbig the units from the radio because at the exact moment when the recorder tries to get the value, the radio hasn't quite gotten around to displaying it yet (maybe the trunking system hasn't transmitted it yet). Be allowing some radio commands to wait for a few milliseconds before execution, the delayed values might be available after the delay.
- The GID command: If you've ever played with the radio in remote command mode (using SR Pro or another program that lets you send the commands, like my UnidenTest.exe), you might have noticed that the GID coimmand only works once per scanner stoppage while scanning a trunking system. If you issue GID more than once per trunking system squelch event, you will receive an empty reply. Since GID only works once, you cannot place more than once GID command (and sub-item #) in the radio job list. The current way the recorder works is that it issues each radio command more than once if it's in the list more than once. Since GID only works one time, keep more than once GID out of the list for now until I implement command reply caching. Then more GID fields will be available to be added to the log. In summary: ONLY ONE GID REPLY FIELD WILL WORK PER VOX EVENT...for now...
The download url and password was changed.
If you want the new password and URL:
Please send me an email with the word DOWNLOAD on the subject line.
Please allow me to confirm your identity by one of the following methods:
Use the email address you used for your donation.
or
Enter your donation transaction ID in the email
or
If you are using a different email than you were when you donated, enter that address into your email.
or