¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

New file uploaded to D-STAR_23cm

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the D-STAR_23cm
group.

File : /D-STAR Programming/dplus and How to Use It.pdf
Uploaded by : wb9qzb_groups <wb9qzb_groups@...>
Description : dplus & How to Use It by National Capital Region D-Star Association

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

wb9qzb_groups <wb9qzb_groups@...>


New file uploaded to D-STAR_23cm

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the D-STAR_23cm
group.

File : /Digital Voice & Data Radios/ID-1 USB Interface Notes.pdf
Uploaded by : wb9qzb_groups <wb9qzb_groups@...>
Description : Icom ID-1 USB Interface Notes by National Capital Region D-STAR Association

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

wb9qzb_groups <wb9qzb_groups@...>


New file uploaded to D-STAR_23cm

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the D-STAR_23cm
group.

File : /High-Speed Digital Data (DD)/ID-1 Troubleshooting Checklist.pdf
Uploaded by : wb9qzb_groups <wb9qzb_groups@...>
Description : Icom ID-1 Troubleshooting Checklist by National Capital Region D-STAR Association

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

wb9qzb_groups <wb9qzb_groups@...>


New file uploaded to D-STAR_23cm

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the D-STAR_23cm
group.

File : /D-STAR Programming/ID-1 Callsign Fields in Repeater Operation.pdf
Uploaded by : wb9qzb_groups <wb9qzb_groups@...>
Description : ID-1 Callsign Fields in Repeater Operation by National Capital Region D-STAR Association

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

wb9qzb_groups <wb9qzb_groups@...>


New file uploaded to D-STAR_23cm

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the D-STAR_23cm
group.

File : /Digital Voice Low-Speed Data/DV Mode Data Communications.pdf
Uploaded by : wb9qzb_groups <wb9qzb_groups@...>
Description : DV Mode Data Communications by National Capital Region D-STAR Association

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

wb9qzb_groups <wb9qzb_groups@...>


SDR Dominates the 2010 ARRL/TAPR Digital Communications Conference

 


SDR Dominates the 2010 ARRL/TAPR Digital Communications Conference

09/27/2010

By Ward Silver, N0AX



The turnout was excellent for the ARRL/TAPR Digital Communications Conference September 23-26 at the in Vancouver, Washington.


The three day conference included technical presentations on both Friday and Saturday, and an optional tutorial seminar on Sunday morning. Both Yaesu and ICOM attended as commercial vendors. Although not present at the conference, Kenwood contributed door prizes.


Software Defined Radio (SDR) was the dominant technical theme of the conference.?Along with independent SDR developers, the Open SDR group gave a status update, George Heron, N2APB, introduced the www.sdr-cube.com/ project and the conference even featured an ¡°introduction to SDR¡± forum. Another discussion that attracted a great deal of attention was a project to adapt analog radios to SDR at the IF.


Other conference highlights included a presentation by Rick Muething, KN6KB, on the status of , the sound-card-based HF digital protocol recently incorporated into Winlink¡¯s RMS Express software package. WINMOR promises performance that rivals PACTOR III at a tiny fraction of the cost. Rick also discussed development of this new V4 protocol for keyboard-to-keyboard communication and was at the podium again Sunday morning with his DSP tutorial.


One of the most anticipated talks was given by Bruce Perens, K6BP, on the new Codec2 digital voice codec. This is an open source project that makes significant advances beyond the vocoder family without any of the licensing and patent issues that have hindered development of Amateur Radio digital voice systems. Bruce stated that by this time next year, the codec should be ready for late-beta deployment on the HF bands.


The complete list of presenters and topics is available at the ?

  • Rick Muething, KN...
  • Mel Whitten, K0PF...
  • N2ADR¡¯s ¡°All Di

All photos by N0AX





Re: Basic question

Tom Azlin N4ZPT
 

If you are in range of that RP-2C/D then when you put your ID-1 in DD RPS, have the call signs right, put in fixed ip/mask/default gateway addresses in you laptop, and plug the ID-1 into the local laptop you should see the radio and the access point talking. If not in range your ID-1/laptop will be trying to connect but you will see nothing coming back.

On range: We see that even when we have 3 bars in the DV mode we sometimes get nothing in the DD mode on the co-located site using same antenna and a triplexer. (no FEC and a 128/4.8 worse path I suppose).

We have put a small laptop behind the RP2C running the network we wanted (ignoring the normal ip address of the 2C) and we then can ping the laptop "server" and access files on that server. That is why I think of it as a bridge but I am not a networking expert. Just manage a complete D-STAR Stack where we are playing with the 23cm DD every once in a while.

Also understand on just a single ID-1 so hard to do testing. We had a gang buy them so started setting up LAN parties to try every thing.

We stashed the docs we had here



73, tom n4zpt

On 9/30/2010 7:54 PM, Dean Gibson AE7Q wrote:
On 2010-09-30 15:30, Tom Azlin N4ZPT wrote:
No and No ["... can two ID-1 sites communicate w/ each other via a local RP-2D site?]
Setting up routes the way Steve Stroh mentioned (each ID-1 has a unique
3rd octet) is simple and easy to do, but (of course) it's a
bastardization of how networking is generally done. With the right
router that supports classless addressing, it should not be necessary to
chew up a whole class C subnet for each ID-1.

I'm in the unfortunate position of having an ID-1 and no one to talk to
in DD mode (or in DV mode, but that may change soon). A friend (Scott
Honaker / N7SS) has an RP-4000V, RP-2D,& RP-2C on a tower nearby, but
w/o an Internet connection. Since (I think) I'm the only one that could
hit it on 23cm, I can't really tell if I am hitting it (I can hit the
70cm unit w/ ease @ 5W).

Hence, I can't experiment, as the RP-2D gives NO on-air indication that
it even exists (let alone powered on, receiving, etc). I think there is
a way to set up IP routing that would work in a more conventional
manner, but I can't test my idea(s).

I can hit the 2m& 70cm modules of the K7LWH system (about 25 miles
away), but not the 23cm DV or DD modules.

My guess is that a few of you are in the same boat as well ...



------------------------------------

Yahoo! Groups Links




Re: Basic question

Tom Azlin N4ZPT
 

Oh, I was saying no to it being a repeater or digipeater.

And no to the two ID-1 communicating via an RP-2C/D with no special routes or servers behind the RP-2C/D. Certainly two ID-1 can make a bridge.

Agreed with all you were saying Peter. It matches our experience these past years. 73, tom n4zpt

On 9/30/2010 7:42 PM, Peter Corbett wrote:
On 2010-Sep-30 13:08 , dean_ae7q wrote:


I have seen conflicting statements about communication between two ID-1
sites that are served by the same RP-2D "repeater" + RP-2C controller.
QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat"
(actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a local
RP-2D site?
Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and doesn't
seem to maintain an ARP table or TCAM or anything like that, at least
not by MAC address. (I suppose it might be doing so based on MY/YOUR calls.)

If you have 2 ID-1s on the same frequency and set to DD RPS, with
cross-matching MY/YOUR calls and sharing the same RPT1 call, then yes,
they form (basically) a point-to-point bridging tunnel between the
ID-1s. Multiple such tunnels should be able to run concurrently, limited
only by available channel time/transmitter duty cycle, etc.

However, a lone 3rd ID-1 can't talk to anyone. For multipoint (ie,
long-distance wireless LAN), you need an IP router hooked into the RP-2C
box. There are a few ways you can set it up (some of which probably
aren't compatible with using the G2 gateway software on the same stack),
but the key part is for each machine to not try talking directly to the
others, but instead to send via the IP gateway. Using a router with a
number of secondary IPs sliced up into /30-sized networks should work,
or you could use PPPoE, or you can play tricks with destination NAT (but
that requires extra special setup for the reverse routing.) As long as
the packets flow from machine A into the controller via the RF port, to
the router, and back to the controller and out via RF again, it should
be fine. Just setting up machines in the same subnet doesn't work,
because the repeater doesn't actually repeat or digipeat; the client
machines will never hear each other's ARP requests.


Re: Basic question

 

On 2010-Sep-30 19:58 , Dean Gibson AE7Q wrote:
On 2010-09-30 16:42, Peter Corbett wrote:
...
can two ID-1 sites communicate w/ each other via a local RP-2D
site?
Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and
doesn't seem to maintain an ARP table or TCAM or anything like
that, at least not by MAC address. (I suppose it might be doing so
based on MY/YOUR calls.)
I didn't expect the RP-2D/2C combo to maintain an ARP table, but I
was hoping that one of the two would just digipeat DD packets.
If you have 2 ID-1s on the same frequency and set to DD RPS, with
cross-matching MY/YOUR calls and sharing the same RPT1 call /[and I
assume RPT2 is programmed w/ the gateway to accomplish this]/, then
yes, they form (basically) a point-to-point bridging tunnel between
the ID-1s.
Hmm, that works? And why is it a tunnel (in the sense that no one
on the local frequency couldn't hear it)?
Hear, but choose to ignore.
More tunnel, in the sense of 'ethernet in here, magic happens, ethernet
out there'.

RPT2 is only used with the Icom gateway and friends; if you're staying
local to the RP-2C, it stays blank, IIRC.

However, a lone 3rd ID-1 can't talk to anyone. ... Just setting up
machines in the same subnet doesn't work, because the repeater
doesn't actually repeat or digipeat; the client machines will never
hear each other's ARP requests.
Hmm, if it works for two ID-1 radios on the same DD module, let's
say that we have several ID-1 radios (say, AAA, BBB, CCC, DDD, etc)
on the same DD module (say, ZZZ), each programmed w/ "ZZZ A" for
Rpt1 and "ZZZ G" for Rpt2, and as follows for UrCall:

AAA: BBB BBB: AAA CCC: AAA DDD: AAA etc: AAA


Now you say that AAA and BBB can communicate (assuming their backing
computers/routers are configured w/ appropriate IP and a common
subnet mask). When BBB ARPs for AAA, that packet goes back out on
the ZZZ output, and surely AAA, CCC, & DDD receive it. Are you
saying that CCC (& DDD, etc) would discard the packet and not send it
through to the RJ-45, because the UrCall doesn't match?
OK, now say that BBB ARPs for CCC. I would think that since BBB is
still programmed with a UrCall of AAA, that ZZZ would send it back
out over the air (intended for AAA), and CCC (& DDD, etc) would see
it just fine (again ignoring the UrCall field), and the backing
computer/router would respond.
Yes, the incoming packet's UrCall doesn't match the local MyCall, so (as
far as I can tell) CCC and DDD would ignore the packet.

I haven't tried having 2 ID-1's who both think they are BBB (but with
different IPs on the machines behind them), but it should work as long
as both BBBs never want to talk to each other.

Similarly, I'm not really sure what the behavior of using UrCall=CQCQCQ
is on DD. I want to say we've tried that, and it isn't as magic a
solution as ought to be.

After all, this is exactly how I understand DV works, with many users
on two different modules: So long as each DV user programs the
UrCall with ANY user's callsign on the *_OTHER_* (remote) module (and
of course sets up Rpt1/2 correctly), all of the users can hear all of
the others. Isn't that correct? And isn't your "cross-matching
MY/YOUR calls" just a technique to fool the gateway into rerouting
the packets back to the originating DD module?
I'll admit that I haven't operated DV at all, but I'd been under the
impression that the convention was to leave the UrCall as CQCQCQ to get
the traditional everyone-hears-everyone behavior, and only to change the
programing of UrCall when you wanted a one-on-one conversation?


Has anyone tried this?

Now if the ID-1 is applying DSQL-type filtering in DD mode, that
would of course stop this in its tracks, but otherwise, it should
work, I'd think (and for more than three ID-1 radios).

Note that in both the DD and DV examples above, AAA doesn't even have
to be on the air for BBB, CCC, DDD, etc to talk to each other. The
only requirement would be that the gateway software would have to
THINK that AAA was on the ZZZ DD module.
...when the gateway software is in use, perhaps. The 'repeater' stacks
I've played with here don't run it at all; they only run an IP router
behind the RP-[12]D.

--
Peter Corbett :: KD8GBL
peter@...


Re: Basic question

Dean Gibson AE7Q
 

¿ªÔÆÌåÓý

On 2010-09-30 16:42, Peter Corbett wrote:
...
 can two ID-1 sites communicate w/ each other via a local RP-2D site?
    
Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and doesn't seem to maintain an ARP table or TCAM or anything like that, at least not by MAC address. (I suppose it might be doing so based on MY/YOUR calls.)
  

I didn't expect the RP-2D/2C combo to maintain an ARP table, but I was hoping that one of the two would just digipeat DD packets.

If you have 2 ID-1s on the same frequency and set to DD RPS, with cross-matching MY/YOUR calls and sharing the same RPT1 call [and I assume RPT2 is programmed w/ the gateway to accomplish this], then yes, they form (basically) a point-to-point bridging tunnel between the ID-1s.

Hmm, that works?? And why is it a tunnel (in the sense that no one on the local frequency couldn't hear it)?


However, a lone 3rd ID-1 can't talk to anyone. ... Just setting up machines in the same subnet doesn't work, because the repeater doesn't actually repeat or digipeat; the client machines will never hear each other's ARP requests.
  

Hmm, if it works for two ID-1 radios on the same DD module, let's say that we have several ID-1 radios (say, AAA, BBB, CCC, DDD, etc) on the same DD module (say, ZZZ), each programmed w/? "ZZZ A" for Rpt1 and "ZZZ G" for Rpt2, and as follows for UrCall:

AAA:? BBB
BBB:? AAA
CCC:? AAA
DDD:? AAA
etc:? AAA


Now you say that AAA and BBB can communicate (assuming their backing computers/routers are configured w/ appropriate IP and a common subnet mask).? When BBB ARPs for AAA, that packet goes back out on the ZZZ output, and surely AAA, CCC, & DDD receive it.? Are you saying that CCC (& DDD, etc) would discard the packet and not send it through to the RJ-45, because the UrCall doesn't match?

OK, now say that BBB ARPs for CCC.? I would think that since BBB is still programmed with a UrCall of AAA, that ZZZ would send it back out over the air (intended for AAA), and CCC (& DDD, etc) would see it just fine (again ignoring the UrCall field), and the backing computer/router would respond.

A similar argument goes for CCC (& DDD, etc) communicating back to AAA or BBB.? Again, unless the ID-1 filters packets based on UrCall, I would think this would work.

After all, this is exactly how I understand DV works, with many users on two different modules:? So long as each DV user programs the UrCall with ANY user's callsign on the _OTHER_ (remote) module (and of course sets up Rpt1/2 correctly), all of the users can hear all of the others.? Isn't that correct?? And isn't your "cross-matching MY/YOUR calls"? just a technique to fool the gateway into rerouting the packets back to the originating DD module?

Has anyone tried this?

Now if the ID-1 is applying DSQL-type filtering in DD mode, that would of course stop this in its tracks, but otherwise, it should work, I'd think (and for more than three ID-1 radios).

Note that in both the DD and DV examples above, AAA doesn't even have to be on the air for BBB, CCC, DDD, etc to talk to each other.? The only requirement would be that the gateway software would have to THINK that AAA was on the ZZZ DD module.

-- Dean 425-338-4276 (Seattle area) if you want to talk in detail, or even on WC7SO/C (usually listening).

ps: Four years ago, someone warned me about asking D-Star questions that might make me look stupid.? I don't mind looking stupid if I gain understanding in the process.? Besides ...







Re: Basic question

Dean Gibson AE7Q
 

On 2010-09-30 15:30, Tom Azlin N4ZPT wrote:
No and No ["... can two ID-1 sites communicate w/ each other via a local RP-2D site?]
Setting up routes the way Steve Stroh mentioned (each ID-1 has a unique 3rd octet) is simple and easy to do, but (of course) it's a bastardization of how networking is generally done. With the right router that supports classless addressing, it should not be necessary to chew up a whole class C subnet for each ID-1.

I'm in the unfortunate position of having an ID-1 and no one to talk to in DD mode (or in DV mode, but that may change soon). A friend (Scott Honaker / N7SS) has an RP-4000V, RP-2D, & RP-2C on a tower nearby, but w/o an Internet connection. Since (I think) I'm the only one that could hit it on 23cm, I can't really tell if I am hitting it (I can hit the 70cm unit w/ ease @ 5W).

Hence, I can't experiment, as the RP-2D gives NO on-air indication that it even exists (let alone powered on, receiving, etc). I think there is a way to set up IP routing that would work in a more conventional manner, but I can't test my idea(s).

I can hit the 2m & 70cm modules of the K7LWH system (about 25 miles away), but not the 23cm DV or DD modules.

My guess is that a few of you are in the same boat as well ...


Re: Basic question

 

On 2010-Sep-30 13:08 , dean_ae7q wrote:


I have seen conflicting statements about communication between two ID-1
sites that are served by the same RP-2D "repeater" + RP-2C controller.
QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat"
(actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a local
RP-2D site?
Yes and no. The RP-2D/RP-2C combo isn't an Ethernet bridge, and doesn't
seem to maintain an ARP table or TCAM or anything like that, at least
not by MAC address. (I suppose it might be doing so based on MY/YOUR calls.)

If you have 2 ID-1s on the same frequency and set to DD RPS, with
cross-matching MY/YOUR calls and sharing the same RPT1 call, then yes,
they form (basically) a point-to-point bridging tunnel between the
ID-1s. Multiple such tunnels should be able to run concurrently, limited
only by available channel time/transmitter duty cycle, etc.

However, a lone 3rd ID-1 can't talk to anyone. For multipoint (ie,
long-distance wireless LAN), you need an IP router hooked into the RP-2C
box. There are a few ways you can set it up (some of which probably
aren't compatible with using the G2 gateway software on the same stack),
but the key part is for each machine to not try talking directly to the
others, but instead to send via the IP gateway. Using a router with a
number of secondary IPs sliced up into /30-sized networks should work,
or you could use PPPoE, or you can play tricks with destination NAT (but
that requires extra special setup for the reverse routing.) As long as
the packets flow from machine A into the controller via the RF port, to
the router, and back to the controller and out via RF again, it should
be fine. Just setting up machines in the same subnet doesn't work,
because the repeater doesn't actually repeat or digipeat; the client
machines will never hear each other's ARP requests.

--
Peter Corbett :: KD8GBL
peter@...


Re: RPS vs simplex

Dean Gibson AE7Q
 

¿ªÔÆÌåÓý

On 2010-09-30 15:32, Tom Azlin N4ZPT wrote:
Do not know details inside the radio but if not in RPS the ID-1 does not try to be a bridge even when the mode is DD.

On 9/30/2010 3:53 PM, Dean Gibson AE7Q wrote:
  
Another question:  on the ID-1, what is the functional/operational difference between "RPS" operation and simplex?  I know RPS operation is for DD operations, but what does it DO?
    


Hmm, I thought the ID-1 in DD mode just passed Ethernet data in either direction w/o changing it, regardless of the "RP" setting.? Perhaps the difference is in the D-Star header?? Perhaps the RP-2C won't route data in simplex mode?? That seems weird.

Or, have you seen instances where the ID-1 would not pass data locally in both directions in simplex mode?

-- Dean


Re: RPS vs simplex

Tom Azlin N4ZPT
 

Do not know details inside the radio but if not in RPS the ID-1 does not try to be a bridge even when the mode is DD.

On 9/30/2010 3:53 PM, Dean Gibson AE7Q wrote:
Another question: on the ID-1, what is the functional/operational
difference between "RPS" operation and simplex? I know RPS operation is
for DD operations, but what does it DO?


Re: Basic question

Tom Azlin N4ZPT
 

No and No

If you put a router behind the RP-2C (or behind the 2c and gateway server) with the right routes (I do not know details but the guys in the Twin Cities area know this) then those at different ID-1 sites can communicate between each other. Otherwise the RP-2C/gateway server just boots the packets over to the default gateway and out to the Internet (or Intranet in my case)

We put servers behind the RP-2C and all just go there for our user here
in the National Capital Region. Like for the Marine Corps Marathon these
past 4-5 years.

73, tom n4zpt

On 9/30/2010 2:08 PM, dean_ae7q wrote:
I have seen conflicting statements about communication between two
ID-1 sites that are served by the same RP-2D "repeater" + RP-2C
controller. QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat"
(actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a
local RP-2D site?


RPS vs simplex

Dean Gibson AE7Q
 

Another question: on the ID-1, what is the functional/operational difference between "RPS" operation and simplex? I know RPS operation is for DD operations, but what does it DO?


Basic question

dean_ae7q
 

I have seen conflicting statements about communication between two ID-1 sites that are served by the same RP-2D "repeater" + RP-2C controller. QuestionS:

When an RP-2D receives an Ethernet DD packet via DD, does it "repeat" (actually, store and forward) the packet to the same frequency?

Or, if the RP-2D doesn't do that, does the RP-2C?

In other words, can two ID-1 sites communicate w/ each other via a local RP-2D site?


Re: WinX64 USB driver for ID-1

dean_ae7q
 

I downloaded the current FTDI serial port driver for Win7 from the FTDI web site (they make the serial chip Icom uses), and that worked after a bit of manual install fiddling around. It's been a few months, so I don't remember the exact details.

-- Dean

--- In D-STAR_23cm@..., James Nelson <jamesnelson_vk2jn@...> wrote:

Well done James,

That's very VERY interesting, now how do we find the x64 driver as it's not on the ICOM USA website last time I looked.

I guess uploading it too the yahoo groups files would violate copyright but that sure sounds promising. Where do you think we should go from here and secondly did the driver require any "non signature enforcement" to activate it on booting up.

I know there are work arounds that have been forward however none particularly user friendly for me.

73'

James

------------------------------
Sent from my iPhone
------------------------------

On 03/09/2010, at 1:28 PM, "n0xia@..." <n0xia@...> wrote:

Some time ago, a few forum members had inquired about running the ID-1 on Win7, which requires a 64-bit usb driver. I suppose this applies to Vista as well. I just acquired a Win7 e-machine laptop (my 1st Win7 pc, previously XP) and needed to install the software for the ID-1. I have two ID-1's. One I bought brand new in 2009 and one I got off of ebay this year. Therefore, I have two cd's for the ID-1 and they are different. The ebay one must be an earlier unit. Its' cd is CD-250603-005, copy-write 2002-2004. The cd for the newer ID-1 is CD-250603-008, copy-write 2002-2007. The newer one has a folder marked WinX64 in the Driver folder. The pc could not successfully auto-install the driver when I plugged in the ID-1 into a usb port. I uninstalled the usb port from the hardware manager, plugged the ID-1 in again and did a manual install when an install wizard of some sort was offered. I selected the WinX64 driver folder and the install was successful.

The software seems to be running OK. I do have a problem adjusting the volume and squelch controls when trying to do a right or left-click with the computers mouse pad or external mouse. I am not sure why that is. I have to click and drag to compensate. That could be the nature of the e-machine. I don't have another Win7 computer to test that assumption, but at least using Win7 with the ID-1 is do-able.

73's

James, N0XIA


Re: DD through the RP2 repeater

Steve Stroh
 

It isn't strictly true that the data transfer can only be from an ID-1
radio to the Access Point and back, but that is the most usual
case.

To configure the Access Point to work more like a classic repeater,
you need an external router and some experience configuring TCP/IP
routers.

Unfortunately I don't quite remember the router configuration
specifics. My vague memory is that all the ID-1s on that AP need to
have unique 3rd octet (apologies for my imperfect TCP/IP terminology).
The router needs to be similarly configured, but at that point, the
ID-1 sending out a packet to another ID-1 will be heard by the AP,
passed along to the router, the router recognizes the different octet,
sends it back to the AP (default route for that octet), AP transmits,
and the other ID-1 hears it.

I was impressed with the "repeater" configuration the Victoria,
British Columbia group did - two ID-1s cabled back-to-back with a
simple crossover Ethernet cable. If memory serves, the TX ID-1 was a
different frequency than the RX ID-1; I'm not sure how they licked the
limitation (at the time) setting the ID-1 to different TX and RX
frequencies in the absence of an official Icom AP.


Thanks,

Steve Stroh N8GNJ

On Tue, Sep 28, 2010 at 07:37, Lloyd <k1lgj@...> wrote:



Thank you. I was hoping there was a way to extend the DD transfer range.

Lloyd
--
steve.stroh@...


Re: DD through the RP2 repeater

 

On 28 Sep 2010, at 15:37, Lloyd wrote:

Thank you. I was hoping there was a way to extend the DD transfer range.
Hi,
My 2 cent
a) configure static routes and turn the computer the ID-1 is connected to into a router
b) configure a routing protocol and turn the computer the ID-1 is connected to into a router
c) use DTN techniques and use those protocols for store-and-forward transfers.

I'm hoping to do all of the above on a 4 'node' network over the next few months.

Regards
de John
EI7IG

Lloyd


--- In D-STAR_23cm@..., "sv1iw" <sv1iw@...> wrote:

Lloyd think of RP2D as an access point (Wifi) through the D-Star system. In that respect you can only get access to the Internet

73 Manos SV1IW

--- In D-STAR_23cm@..., "Lloyd" <k1lgj@> wrote:

I have succeeded in accessing the internet with DD. I have also transferred large files between two ID-1s. I can even send emails and ICS 213s. All this is good.

My question is how do I set up to send DD files through the RP2-D repeater (if it can be done)?

Please give me all settings.



73

Lloyd, K1LGJ


Admin

KE5RCS



------------------------------------

Yahoo! Groups Links