Re: [Hamlib-developer] hamlib
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
Re: [Hamlib-developer] hamlib
|
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 |
