be done for the Atlanta RN-171-XV.
Since there are no static IP addresses at either end of
the link and the 192.168.0.xxx addresses are not routable
on the Internet, we must have a way to contact the Atlanta
router from Key West using a routable IP address. The
problem is that the Atlanta router’s IP address is apt to be
changed at any time by the ISP (Internet Service Provider)
servicing the Atlanta router’s Internet connection. So, to
make sure we can always find the Atlanta router, we’ll set
up a DynDNS (Dynamic DNS) entry for it. Then, all we need
to know is Atlanta’s local port number which is configured
in the Atlanta router and the Atlanta RN-171-XV. That port
number happens to be 8000.
DynDNS is a billable service ($20 a year) that allows the
association of an Internet device IP address with a unique
host name. If the host router IP address changes, DynDNS
sees that and associates the Atlanta router’s new IP address
with the respective host name. For instance, the Atlanta
H-bridge controller’s DynDNS host name is atlanta
hbridge.DynDNS-remote.com. No matter what IP address
the Atlanta router adopts, the IP address will always be
associated with the DynDNS host name. So, to contact the
Atlanta router, all we need to do is enter the DynDNS host
name we set up on the DynDNS website (atlantahbridge.
DynDNS-remote.com), followed by the local port number
assigned to the Atlanta RN-171-XV (8000).
The Atlanta and Key West routers must be capable of
supporting the DynDNS service. Most all of the current
routers on the market today support this service.
SCREENSHOT 2. Setting
up the parameters in the IP
and WLAN areas provides
enough information to get
the RN-171-XV online.
//***********************************************
//* USART Receive Character Function
//***********************************************
unsigned char recvchar(void)
{
unsigned char tmptail;Florida-Georgia Dry Run
We can test the feasibility of our remote H-bridge
application right here on the bench. The PIC18F46J13-
based Atlanta node is pictured in Photo 4. We are primarily
interested in the H-bridges. However, the Atlanta H-bridge
controller can also provide remote access to a pair of DPDT
relays, two optically isolated inputs, several digital I/O pins,
microSD storage, and an auxiliary device socket. The
object of this test session is to contact the Atlanta
H-bridge node and issue a simple command to activate
and deactivate an H-bridge output. First, we must load
the Atlanta node with the appropriate receiver code:
while ( USART_RxHead == USART_RxTail );
// wait for incoming data
tmptail = ( USART_RxTail + 1 ) &
USART_RX_BUFFER_MASK;
// calculate buffer index
USART_RxTail = tmptail;
// store new index
return USART_RxBuf[tmptail];
// return data
}
//***********************************************
//* USART Character Waiting Function
//***********************************************
unsigned char CharInQueue(void)
{
return(USART_RxHead != USART_RxTail);
}#INT_RDA2
void RDA2_isr(void)
{
unsigned char data,i;
unsigned char tmphead;
data = RCREG2; //read the received data
tmphead = ( USART_RxHead + 1 ) &
USART_RX_BUFFER_MASK;
USART_RxHead = tmphead; //store new index
if ( tmphead == USART_RxTail )
{
//ERROR HAS OCCURRED - RESET THE RECEIVER
//bit_clear(CREN2);
//bit_set(CREN2);
}
USART_RxBuf[tmphead] = data;
//store received data in buffer
}
SCREENSHOT 3. Tera Term is a luxury here. We can also use the
Windows or Android Telnet applications to contact the Atlanta
H-bridge node. In fact, anything that can run as a Telnet client
can access the Atlanta H-bridge node.
SERVO 06.2013 55
