Thread: [Hamlib-developer] hamlib
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: <wi...@bt...> - 2002-04-26 22:01:14
|
hi Stephane I have been looking for something which your project may prove suitable. As an Amateur Software developer using VB5/6, I am looking for a rig CAT interface for my software "Winlog32", this is a general purpose free logging program with quite a good number of users world-wide. Many of these users have asked me for a simple rig interface to swap frequency/mode data with the program. I have looked at the possibility of doing this myself directly but it is a large undertaking with so many rigs all using different protocol, with no rigs to test on myself and I really do not have the time to do it anyway. Does your project use a DLL or OCX that could be used by VB? If so how may I obtain it? From your web site the downloaded file formats are unfamiliar to me! Can you help. regards Colin G0CUZ wi...@bt... www.winlog.co.uk |
|
From: Mike S. <k0t...@qw...> - 2009-10-17 02:48:52
Attachments:
error.log
|
rigmem on Ubuntu 9.04 Linux does not work with IC-756PROIII rigmem -m 357 -r /dev/ttyS1 -s 19200 -c 0x6E ---v save attached is what I could capture using the ----v option. The radio's memories were changed. It appears that ALL of the memories with SSB mode stored had the bandwidth changed to 400 Hz. That's all the information I have. 73, Mike, K0TER |
|
From: Stephane F. <f8...@fr...> - 2009-10-17 15:43:53
|
Mike Stansberry wrote: > rigmem on Ubuntu 9.04 Linux does not work with IC-756PROIII > Thanks for the report. Under Jaunty, this is version 1.2.8-1ubuntu1, right? > rigmem -m 357 -r /dev/ttyS1 -s 19200 -c 0x6E ---v save > For your convenience, the options "-s 19200" and "-c 0x6E" are not necessary for the IC-756PROIII because they are already the default (highest speed, and default CI-V address). To review the defaults: rigctl -m 357 -u BTW, the backend status is Untested. Would you like to volunteer for testing it as you already started to? Are you familiar with compiling a program from source package? Maybe can you understand/do some C programming? In any case, beta-testing is still very much appreciated. The latest official Hamlib release is 1.2.9, but some changes have accumulated since (yes, we need a new release 1.2.10). In-between, these changes are available in the development daily snapshot here: http://n0nb.users.sourceforge.net/ You'll find the file README.betatester helpful. Testing the Hamlib backend is done using rigctl. Rem: subversion VCS is the best method to pick up latest changes. > attached is what I could capture using the ----v option. > Thanks, this is very helpful. The appropriate syntax is -vvvvv ;-) > The radio's memories were changed. It appears that ALL of the > memories with SSB mode stored had the bandwidth changed to 400 Hz. When you say that "The radio's memories were changed", do you mean they were changed by a rigmem load command? Can you please test mode setting on a regular VFO first? This is command 'm' and 'M' under rigctl. For example: Rig command: M Mode: USB Passband: 2400 Passband is in Hz, latest "rigctl -m 357 -u" reports available's: Bandwidths: AM normal: 6 kHz, narrow: 2.4 kHz, wide: 0 Hz CW normal: 500 Hz, narrow: 50 Hz, wide: 3.6 kHz USB normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz LSB normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz RTTY normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz FM normal: 15 kHz, narrow: 8 kHz, wide: 0 Hz CWR normal: 500 Hz, narrow: 50 Hz, wide: 3.6 kHz RTTYR normal: 2.4 kHz, narrow: 50 Hz, wide: 3.6 kHz According to fine DF4OR's site[1] (thanks Ekki!), regarding Passband data and IC756PRO*: "...And when looking at the DSP-filter rigs like IC-756Pro ff., where the user can define and arrange each of the three filters individually, the settings of 'wide' or 'narrow' become meaningless. Here a filter value of $01 corresponds to filter 1, value $02 to filter 2 and $03 to filter 3, regardless of whether filter 1 is acutally wider than filter 2 or 3." [1] http://www.plicht.de/ekki/civ/civ-p33.html Even Hamlib 1.2.8 should have passband width retrieval OK, however, finer width setting looks missing. For hamlib developpers, please have a look at the function icom_set_dsp_flt() just committed into svn. Does anybody with an Icom*Pro can hack icom_set_mode() and test icom_set_dsp_flt() ? > > That's all the information I have. > > 73, Mike, K0TER Attached file: error.log: > icom_get_split_vfo: wrong frame len=0 That's unfortunate, this rig appears to not be able to report the split status. > TX 6 bytes > 0000 fe fe 6e e0 0f fd ..n... > RX 6 characters > 0000 fe fe 6e e0 0f fd ..n... > RX 6 characters > 0000 fe fe e0 6e fa fd ...n.. > icom_get_rptr_shift: wrong frame len=0 No rptr_shift support. > TX 6 bytes > 0000 fe fe 6e e0 0c fd ..n... > RX 6 characters > 0000 fe fe 6e e0 0c fd ..n... > RX 6 characters > 0000 fe fe e0 6e fa fd ...n.. > icom_get_rptr_offs: wrong frame len=0 Ok, not available on this rig, through this command anyway. > TX 6 bytes > 0000 fe fe 6e e0 12 fd ..n... > RX 6 characters > 0000 fe fe 6e e0 12 fd ..n... > RX 8 characters > 0000 fe fe e0 6e 12 00 00 fd ...n.... > icom_get_ant: ack NG (0x12), len=3 This is a new format for IC756PROIII with RX ANT reporting. Fixed right now in svn repository. > TX 6 bytes > 0000 fe fe 6e e0 10 fd ..n... > RX 6 characters > 0000 fe fe 6e e0 10 fd ..n... > RX 6 characters > 0000 fe fe e0 6e fa fd ...n.. > icom_get_ts: wrong frame len=0 Looks like the rig is unable to report the current Tuning Step? > TX 7 bytes > 0000 fe fe 6e e0 16 02 fd ..n.... > RX 7 characters > 0000 fe fe 6e e0 16 02 fd ..n.... > RX 8 characters > 0000 fe fe e0 6e 16 02 00 fd ...n.... > icom_get_level: 1 0 0 0.000000 > TX 6 bytes > 0000 fe fe 6e e0 11 fd ..n... > RX 6 characters > 0000 fe fe 6e e0 11 fd ..n... > RX 7 characters > 0000 fe fe e0 6e 11 00 fd ...n... > icom_get_level: 1 0 0 0.000000 > TX 7 bytes > 0000 fe fe 6e e0 14 01 fd ..n.... > RX 7 characters > 0000 fe fe 6e e0 14 01 fd ..n.... > RX 9 characters > 0000 fe fe e0 6e 14 01 00 48 fd ...n...H. > icom_get_level: 2 48 1044431041 0.188235 Und so weiter.. [...] > TX 6 bytes > 0000 fe fe 6e e0 03 fd ..n... > RX 6 characters > 0000 fe fe 6e e0 03 fd ..n... > RX 11 characters > 0000 fe fe e0 6e 03 00 20 55 03 00 fd ...n.. U... Here is the get_mode: > TX 6 bytes > 0000 fe fe 6e e0 04 fd ..n... > RX 6 characters > 0000 fe fe 6e e0 04 fd ..n... > RX 8 characters > 0000 fe fe e0 6e 04 03 02 fd ...n.... ^^ ^^ $03 is CW (and not SSB), $02 is medium(normal) passband width. > TX 7 bytes > 0000 fe fe 6e e0 1a 03 fd ..n.... > RX 7 characters > 0000 fe fe 6e e0 1a 03 fd ..n.... > RX 8 characters > 0000 fe fe e0 6e 1a 03 07 fd ...n.... ^^ The IF filter setting query: $1a $03, which corresponds to 400 Hz. IMHO, the rigmem save command (and get_mode) works fine, but the load (and set_mode) doesn't, regarding the passband width. More investigation needed.. 73 -- Stephane - F8CFE |
|
From: Stephane F. <f8...@fr...> - 2002-04-27 07:52:22
|
Hi Colin, First of all, thanks for your interest in Hamlib. The idea behind this library is to serve as an abstraction layer, kind of "driver", and not having to reinvent the wheel each time someone write some Amateur software. So far, Hamlib is rather POSIX oriented, mainly from the developpers culture (hence the unfamiliar downloaded file format you downloaded :). However, we are very willing to see Hamlib in use on Win32 systems, as well as Mac OS. All in all, the protocol handling code is quite portable, the build environment isn't. Actually, I've started some porting work with cygwin (POSIX environment under windows), and Mac OS X. The sourceforge compile farm helps a lot on the Mac OS X front, and provided libltdl has the right patch, this should be okay for this platform. Talking about Windows, the port is not complete. The problem is I don't need myself Hamlib under Windows, and also I don't use VC/VB, just cygwin. That's why there's no DLL in the download section. But I'm still ready to work on this port, as long as there's some beta testers for this platform. And it looks like you're the one (with the good number of users world-wide). So let's do it. I have a question. What are OCX used for? To my (limited) understanding, this is VB only stuff. Am I wrong? Would a DLL be enough for what you need? As you can see, I don't know anything of VB. I guess the DLL file is not enough. Do you need anything else like header files? or some API entry list as XBasic do? So far, using cygwin, I've been able to generate a DLL. Having applications be able to use it is another story. DLL is such a mess. Why everything has to be so much complicated under this platform? My test program can access the frontend, not the backend. Anyway, Hamlib is a bit tricky too. This is a shared library, the frontend, that should be able to load "plugins" (again shared libraries, the backends). Imagine the nightmare it can be when you want to support multiple platforms. Trust me, C code portability is nothing compared to compile and linking issues. Anyway, thanks to autoconf/automake/libtool, we should be able to get away with it. To make it simpler on win32, we may choose to obtain a single DLL, embedding all the backends (> 1MB). This DLL would be generated by cygwin tools. However, I'm wondering if VC++/VB will be able to grok it. If it's not working okay (and you will tell me), I think we'll have to not use the autotools for generating the DLL, and use VC to compile it instead. This will have to be sorted out. And don't worry, even though you have no rig to test Winlog32 with, there's a dummy backend that just logs traces of calls, which is very useful for debugging. As a conclusion, I would say Hamlib is not yet usable on Win32, but if you're willing to, we can do the last mile together to get it working. Are you interested in? Regards Stephane - F8CFE |
Thanks for helping keep SourceForge clean.
X