Unexpected bytes received by RN-131

Wireless & IoT
1

I’m trying to test a small HTTP server based on WIFLY module RN131 and an AVR micro in my wifi home local network.

I know that this device is designed to work as a client, however in my case I find a strange behaviour that i cannot explain and don’t know if related to the design of this module or if I am missing something in module setup.

Here is my test:

After power on the server correctly joins my home network and is listening on port 2000. His IP address is 192.168.1.2.

From a browser (firefox on PC or on Android device connected to my wifi) i fill the following URL line: http://192.168.1.2:2000/LEDON.

The browser sends the following HTTP requests:

GET /LEDON HTTP/1.1

Host: 192.168.1.2:2000

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: keep-alive

Upgrade-Insecure-Requests: 1

Pragma: no-cache

Cache-Control: no-cache

This request is correctly received from the RN131 serial port, and is processed by the AVR program (led is turned on).

After this, the server sends back the following HTTP response to the RN131 serial port:

HTTP/1.1 200 OK

Content-Length: 49

Content-Type: text/html; charset=utf-8

Connection: Closed

Led turned on!

Looking at the data received at the browser side, i see many bytes of garbage (mainly 0xFF’s - ASCII ÿ ) around the HTTP response sent by the server like this:

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿHTTP/1.1 200 OK

Content-Length: 49

Content-Type: text/html; charset=utf-8

Connection: Closed

Led turned on!

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

This doesn’t allow the browser to format the HTML message in the <body….

Has someone an idea why these bytes generated by the RN-131 serial port?

Thanks and regards.

2

Which serial connection / pins do you use ?

3

I’m using PIN 13( UTX) and Pin 12 (URX) for serial communications.

4

Need a bit more information in order to try to help.

Which AVR micro do you use ?

Which RN-131 board/shield do you use ?

example or link to the sketch and/or library ?

5

I’m using an ATMEGA32 board with an RN131G-I/RM shield. The only two signals connected between AVR and RN131 are the UART TX and RX.

The RN131 was setup to join my existing Access Point (SSID) at power on, show its IP address on a LCD and just listen for data on port 2000.

When a connection is done from a browser, the AVR UART receives bytes from the RN module, that i put into a buffer.

When the incoming message (HTTP request) has been received (no more characters received in a given time) I process the message and I wish to send back the HTTP response, simply writing it to the serial port. It is very simple, BUT i’m not sure if this is the right way to do this.

I’m not using any library (like Arduino wifly) since I would keep the AVR program as simple as possible. In addition I am not using the wifly GPIOs to control the IP connection.

This is the first time that I play with RN131 and wish to use it as a HTTP server, even if documents say that it must be used as client…

6

I would not expect this issue to be because of client or server configuration. I suspect that the TX connection from the ATMEGA32 to the RX on the RN311G is causing noise.

Maybe the pin on the ATMEGA32 is also used for something else at the same time. If you just write to the serial output port, that port is often times also used for the USB/FTDI connection with your PC (hence my question about the board to check). Or an issue with baudrate/databits/parity setting or floating signal on the line (although the specification do not talk about pull-up/pull-down resistors)

regards,

Paul

7

Paul, thanks for your answer.

I’ve tried this with two different RN131 modules with the same results. I would expect, if the baud rate is nor set up correctly, that the response sent should have garbage, while it seems not.

I attach here a sketch of the AVR program (only relevant code) for completeness.

It seems that the transmission of the response with garbage starts when the tcp connection is closed (after a timeout set in RN module).

What do you mean that the serial port is also used for USB/FTDI connection with PC? The AVR is only connected to the wifly module and the PC is connected to the same network via wi-fi.

/*
 * ServerTest.c
 * Author : alfo48
 */ 

#define F_CPU 14745600UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define bufsize 1024
#define LED_PORT 		PORTA
#define RX_LED			PA2
#define TX_LED			PA3
#define LED				PA4 


#define REQUEST_READY	7
#define BUFFER_FULL		6

//*********************************************************************************
//   MACROS
//*********************************************************************************
// TX e RX Leds ON when PORTA bit is LOW
#define OFF_RX_LED()			LED_PORT |= (1<<RX_LED)
#define ON_RX_LED()				LED_PORT &= ~(1<<RX_LED)

#define OFF_TX_LED()			LED_PORT |= (1<<TX_LED)
#define ON_TX_LED()				LED_PORT &= ~(1<<TX_LED)

#define OFF_LED()				LED_PORT |= (1<<LED)
#define ON_LED()				LED_PORT &= ~(1<<LED)

#define Set_REQUEST_READY()		flags1 |= (1<<REQUEST_READY)
#define Set_BUFFER_FULL()		flags1 |= (1<<BUFFER_FULL)
#define Clear_REQUEST_READY()	flags1 &= ~(1<<REQUEST_READY)
#define Clear_BUFFER_FULL()		flags1 &= ~(1<<BUFFER_FULL)

//*********************************************************************************
//   PROTOTYPES
//*********************************************************************************
void	WaitForRequest(void);
void	DebugBuffer(char* s);
void	Delay(uint16_t dly);
void	Init_MPU (void);
void	ResetBuffer(void);
void	SendToUart(char * s);

//*********************************************************************************
//   RAM VARIABLES
//*********************************************************************************
unsigned char			flags1;
unsigned char			leds;
unsigned int			numchars;				// Numero caratteri di una richiesta HTTP
volatile unsigned int	timer;
volatile unsigned char	rx_timeout, tx_timeout;
char					Buffer[bufsize];


//*********************************************************************************
// TIMER0 (CTC) INTERRUPT EVERY 1 MSEC
//*********************************************************************************
ISR(TIMER0_COMP_vect)
{
	if (rx_timeout > 0) 
	{
		if (--rx_timeout == 0)
		{
			OFF_RX_LED();					// when RX timeout expires turn off RX LED
			Set_REQUEST_READY();			// indicate that a packet has been received
		}
	}
	if (tx_timeout > 0)
	{
		if (--tx_timeout == 0)				// when TX timeout expires turn off RX LED
		{
			OFF_TX_LED();
		}
	}	
	if (timer) timer --;					// Decrement Delay timer
}

//*********************************************************************************
//  RECEIVE COMPLETE INTERRUPT 
//*********************************************************************************
ISR(USART_RXC_vect)
{
	char c;
	c = UDR;
	if (numchars < bufsize) 
	{
		Buffer[numchars]= c;					
		numchars++;								
	}
	else Set_BUFFER_FULL();
	rx_timeout = 2;							// Set 2 ms RX timeout							
	ON_RX_LED();							// Turn on RX led
									
}

//*********************************************************************************
//  RESET BUFFER  
//*********************************************************************************
void ResetBuffer(void)
{
	memset(Buffer,0,bufsize);				// Clear buffer
	numchars = 0;
}

// *********************************************************************************
//    DELAY FUNCTION  (min 10 ms, max 655.350 msec)
// *********************************************************************************
void Delay(uint16_t dly)
{
	timer = dly;
	while (timer > 0);
}

//*********************************************************************************
// SEND TO UART
//*********************************************************************************
void SendToUart(char * s)
{	
	unsigned int i;
	for (i=0; s[i]!=0; i++)
	{
		while ( !( UCSRA & (1<<UDRE)) );				// Wait until trasmitter free	
		UDR = s[i];										// Transmit current char
		ON_TX_LED();									// Turn on TX_Led
		tx_timeout = 5;									// Set 5 ms tx_timeout
	}
}


// *********************************************************************************
//   INIT MPU
// *********************************************************************************
void Init_MPU (void)
{
	// Set up PORTs direction

	DDRA = 0b11111100;						//

	leds = 0x1c;							
	PORTA = leds;							// Turn off leds
	
	// Setup Timer0 in CTC mode to signal every 1 msec
	OCR0  = 0x39;							// number to count up to
	TIFR |= 0x02;							// clear interrupt flag
	TIMSK = 0x02;							// TC0 compare match interrupt enable
	TCCR0 = 0x0c;							// clock source CLK/256, start timer

	// Setup UART 
	#define BAUD_PRESCALE_9600 (((F_CPU / (9600 * 16UL))) - 1)
	UBRRL = BAUD_PRESCALE_9600;				// Load lower 8-bits into the low byte of the UBRR register
	UBRRH = (BAUD_PRESCALE_9600 >> 8);		// Load upper 8-bits into the high byte of the UBRR register
		
	// Enable receiver and transmitter and "receive complete interrupt" of UART
	UCSRB = ((1<<TXEN)|(1<<RXEN) |(1<<RXCIE));		
	sei();									// Global interrupt active
}


// *********************************************************************************
//   WAIT FOR HTTP REQUEST
// *********************************************************************************
void	WaitForRequest(void)
{
	ResetBuffer();											// Init buffer
	Clear_REQUEST_READY();
	while (!(flags1 & 1<<REQUEST_READY));					// Loop here until a packet has been received
}

// *********************************************************************************
//		MAIN
// *********************************************************************************
int main(void)
{
	char * ip;
	Init_MPU();
	Delay(5000);											//Allow some time to join my wifi network	
	LCD_Init();
	if ((ip = strstr(Buffer,"IP="))) ip[16+3] ='\0';		// Isolate the IP= information						
	if (ip) LCD_write (ip+3);								// and put it to LCD
	Delay(1000);

	while (1)
	{
		WaitForRequest();									
		SendToUart("\n\n");
		Delay(30);
		//DebugBuffer(Buffer);
		if (Buffer[15] =='N') ON_LED();

		Delay(800);

		SendToUart("HTTP/1.1 200 OK\n\n");
		SendToUart("Content-Length: 49\r\n");
		SendToUart("Content-Type: text/html; charset=utf-8\r\n");
		SendToUart("Connection: Closed\r\n");
		SendToUart("\r\n");
		SendToUart("<html><body><h1>Led turned on!</h1></body></html>\r\n");				
		SendToUart("\r\n");	
		Delay(1000);					
	}
}
8

I don’t see anything wrong or that worries me in the code. My remark about the USB/FTDI is that you have upload your compiled/Hex code to the ATMEGA. For that you have your AVR is connected to a ‘PC’. Also if when you use a serial monitor. It might be that they connect to the same UART.

regards,

Paul

P.s. found a link where they had issues with display strings… turned out to be the serial monitor (working good with Putty)… not sure this could give a glue

https://www.avrfreaks.net/forum/usart-s … destk500v1

9

After a LOT of reading about RN-131 documents and many different tries configuring RN-131 ( set comm time and set comm size parameters) I always find that the wifly module sends the 0xFF’s when the TCP connection gets closed automatically. At this time the TX led shows the trasmission activity.

I’m sure that the program is sending ONLY the HTTP response, while the 0xFF’s are generated internally by the wifly module.

So at this time I’m almost sure that what I was expecting (HTTP server) cannot be done by design, unless someone which has already experimented this can give me any other clue.

Anyway many thanks to Paul for his kind help.

Alfonso

10

Resolved!!!

The problem was solved using two different DC sources for AVR board and RN-131 shield. Using the same ground plus TX and RX signals everything was OK.

11

Would you mind telling the voltages? AFAIK the RN-131 works on 3.3V but newer versions work on 1.8V only. What are your sources’ voltages?