433MHz module probleem

het probleem is als volgt. Ik heb 2 RF modulen, een zender en ontvanger. Ik dacht dat het gewoon een kwestie was van de UART van de uC aansluiten op "data-in/uit". Blijkbaar is dit niet zo want het werkt niet.

Het gaat om deze modulen (conrad):
- ontvanger
- zender

De ontvanger ontvangt wel iets maar kan niet zien wat... wanneer ik de TX van de pc aan de RX van de uC hang, zie ik wel mijn data (continu zelfde karakter sturen) terug.

heeft dit iets met FSK te maken?

[Bericht gewijzigd door Marcel (5) op vrijdag 25 januari 2008 14:29:13 (13%)

dus op de data-in en uit moet ik een frequentie van 2KHz aanbieden als logische "0" en bijv. 3 KHz als logische "1"??

Frederick E. Terman

Honourable Member

Nee, bij FSK slaat de "F" op het hoogfrequent.
Wat jij bedoelt zou dan AFSK heten - Audiofrequentie shift keying.

Keramisch, kalibratie, parasitair: woordenlijst.org

Je moet manchestercode gebruiken.
Google is je vriend ;-)

@ 2N3055:

thanks, ik kwam er net achter dat ie het wel doet als ik vaker hetzelfde karakter stuur.... dus ga me nu idd verdiepen in die manchestercode!

Als ik de datasheets bekijk, vermeldt de fabrikant dat het FSK is maar volgens mij is het (effectief) gewoon OOK (On Off Keying).

Op pin 13 van de ontvanger kan je het gedetecteerde signaal monitoren. De ontvanger heeft gewoon een AM demodulator, geen FSK demodulator.

Bart Hiddink is Ideetron; electronics and projects, http://www.ideetron.nl. LoRaWAN Nutcase.

ben nu een stuk wijzer geworden dankzij alle documentatie. Ik zit te twijfelen tussen 2 methoden:

1. Manchester codering
2. Packet met veel overhead (meerdere startbytes)

als ik manier 1 goed begrijp:

stel je hebt 0xFF = 11111111, dit wordt dan: 1010101010101010 en heb je vervolgens dus 2 bytes nodig om dit te versturen? Manchester zegt alleen iets over de daadwerkelijke data (dus zonder start/stopbits en parity check)?

Is nu het doel van Manchester codering om meer wisselingen tussen 1 en 0 te krijgen zodat de UART eerder is geinitaliseerd?

Nee, Met manchesterencoding kan je makkelijker clockrecovery doen.

http://en.wikipedia.org/wiki/Manchester_code

Maar als ik naar de datasheet kijk hoef je helemaal geen manchester te gebruiken. Volgens mij als je een 1 instuurt moet je ook een 1 uit de ontvanger krijgen. En dan maakt het niet uit hoe snel ( met een maximum van 30kHz. :+ )

[Bericht gewijzigd door jovak op vrijdag 25 januari 2008 23:05:38 (67%)

meten is weten, weten is meten, maar hoe kan je weten wat je allemaal moet meten en weten.

code:

DATA FORMAT: <FF> | <00> | <FF> | <00> | <FF> | <80> | 8 x <DATA> | <ERROR = 13> | <ERROR = 50> |

heb nu dit frame bedacht. Werkt perfect, gaat nooit fout tot nu toe, ook niet als ik met andere zender probeer te storen :D

bij de ontvangende code:

1. controleer of de huidige waarde = 80 en de vorige waarde = 255
2. haal de data op (nu 8 bytes groot, kan in toekomst groter)
3. controleer of het eerste errorbyte = 13, zo nee stoppen
4. controleer of het 2de errorbyte = 50, zo nee, stoppen
5. beide errorbytes goed, verwerk de data!

http://www.digitalesnelweg.com/Bestanden/pic1.jpg

http://www.digitalesnelweg.com/Bestanden/pic2.jpg

heb nu soort chat programma gemaakt één richting op dan :P
elke letter die in het tekstvak wordt getypt wordt direct weergegeven op het LCD (atmega32 op dit moment).

heb het nog steeds niet fout zien gaan

Frederick E. Terman

Honourable Member

Leuk dat het toch werkt. Wat ik wel grappig vind is hoe je zo even een foutdetecterende code hebt gemaakt.

Keramisch, kalibratie, parasitair: woordenlijst.org

Welke taal heb gebruikt voor je AVR, en hebt je ook een source code?

Op 25 januari 2008 23:16:31 schreef Marcel (5):

code:

DATA FORMAT: <FF> | <00> | <FF> | <00> | <FF> | <80> | 8 x <DATA> | <ERROR = 13> | <ERROR = 50> |

heb nu dit frame bedacht. Werkt perfect, gaat nooit fout tot nu toe, ook niet als ik met andere zender probeer te storen :D

bij de ontvangende code:

1. controleer of de huidige waarde = 80 en de vorige waarde = 255
2. haal de data op (nu 8 bytes groot, kan in toekomst groter)
3. controleer of het eerste errorbyte = 13, zo nee stoppen
4. controleer of het 2de errorbyte = 50, zo nee, stoppen
5. beide errorbytes goed, verwerk de data!

Je zou nog een CRC kunnen maken ipv alleen naar de 2 laatste bytes te kijken.

Je telt dan alle databytes op en stuurt als foutdetectie byte de modulo255 waarde van de uitkomst mee.

data ascii
H 104
E 101
L 108
L 108
O 111
064
! 065
! 065
============
totaal 726

726 = 2 *255 + 216

Dit kan je in een microcontroller simpel doen door de byte waardes in een byte op te tellen. De waarde die in die byte staat na alle bytes opgeteld te hebben stuur je mee als error code. Je let dan niet op de overflow van die byte.

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

meten is weten, weten is meten, maar hoe kan je weten wat je allemaal moet meten en weten.
Arco

Special Member

>> Je zou nog een CRC kunnen maken ipv alleen naar de 2 laatste bytes te kijken.
>> Je telt dan alle databytes op en stuurt als foutdetectie byte de modulo255 waarde van de uitkomst mee.

Dat is geen CRC, maar een checksum.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

naar mijn wete hangt een beetje van de module af. maar er zijn toch modules waar je gewoon rechtstreeks rs232 kunt insteken en waar dan ook terug rs232 terug uitkomt
eventueel zou je nog een crc ofzo kunnen toevoegen dat wel.

My Tube is bigger then yours

Op 27 januari 2008 05:21:11 schreef Arco:

Dat is geen CRC, maar een checksum.

van de wikipediapagina. eerste alinea.

A cyclic redundancy check (CRC) is a type of function that takes as input a data stream of any length and produces as output a value of a certain fixed size. The term CRC is often used to denote either the function or the function's output. A CRC can be used as a checksum to detect accidental alteration of data during transmission or storage

meten is weten, weten is meten, maar hoe kan je weten wat je allemaal moet meten en weten.
Frederick E. Terman

Honourable Member

Een CRC is een algemeen begrip. Gaat met deling door een polynoom.
Als de polynoom heel simpel is (bv. x1) dan krijg je hetzelfde als de simpele checksum.
Betere CRC's werken met langere polynomen.

Keramisch, kalibratie, parasitair: woordenlijst.org

hehe, het programmeren heb ik gedaan in C (AVR studio), dit is ook niet echt het probleem.... ik had al nagedacht over die CRC, ga ik er van der week ff inbakken. De code in de interrupt service routine is:

code:

ISR(USART_RXC_vect)
{
//DATA FORMAT: <FF> | <00> | <FF> | <00> | <FF> | <80> | 20 x <DATA> | <ERROR = 13> | <ERROR = 50> |

	ontvangen = UDR;
	
	if(data_detected == 1)
	{	
		if(read_count < 20)
		{	
			data[read_count] = ontvangen;
			read_count++;
		}
		else
		{
			if(read_count == 21)
			{
				if(ontvangen == 50)
				{
					vorige_waarde = 0;
					read_count = 0;
					data_detected = 0;
					data_ready = 1;
				}
				else
				{
					vorige_waarde = 0;
					read_count = 0;
					data_detected = 0;					
				}
			}

			if(read_count == 20)
			{
				if(ontvangen != 13)
				{
					vorige_waarde = 0;
					read_count = 0;
					data_detected = 0;					
				}
				else
				{
					read_count++;
				}
			}
		}
	}
	else
	{
		if(ontvangen == 80 && vorige_waarde == 255)
		{
			data_detected = 1;
			read_count = 0;
		}
		vorige_waarde = ontvangen;
	}

}

vervolgens kan je in de Main steeds "pollen" op data_ready.

in 1 richting data is goed te doenmet een simpele checksum.
je blijft gewoon sturen en aan de ontvanger kant geef je alleen data uit als de checksum ok is

My Tube is bigger then yours

in 1 richting data is goed te doenmet een simpele checksum.
je blijft gewoon sturen en aan de ontvanger kant geef je alleen data uit als de checksum ok is
eventueel een extra uitgang die aangeeft of het correct is of niet.
al wat niet correct is negeer je dan gewoon. je kan geen data recoveren maar aangezien de aanvoer constant nieuwe data geeft zal alleen de verversing er onder lijden wat niet zo'n ramp is denk ik. als er al fouten optreden he!

My Tube is bigger then yours

zo, de CRC zit erin:

code:

ISR(USART_RXC_vect)
{
//DATA FORMAT: <FF> | <00> | <FF> | <00> | <FF> | <80> | 20 x <DATA> | <CRC> |

	ontvangen = UDR;
	
	if(data_detected == 1)
	{	
		if(read_count < 20)
		{	
			data[read_count] = ontvangen;
			crc_byte = crc_byte + data[read_count];
			read_count++;
		}
		else
		{
			//CRC check
			while (crc_byte > 255)
			{
				crc_byte = crc_byte - 255;
			}

			if(crc_byte == ontvangen)
			{
				//Juiste data
				reset_vars();
				data_ready = 1;
			}
			else
			{
				reset_vars();
				crc_byte = 0;
			}

		}
	}
	else
	{
		if(ontvangen == 80 && vorige_waarde == 255)
		{
			data_detected = 1;
			read_count = 0;
		}
		vorige_waarde = ontvangen;
	}

}

in VB6 wordt de CRC-byte op deze manier bepaald:

code:

Public Function determine_crc()

    Dim crc_byte As Integer
    i = 6
    While i < 26
        crc_byte = crc_byte + data(i)
        i = i + 1
    Wend
    
    While crc_byte > 255
        crc_byte = crc_byte - 255
    Wend
    
    data(26) = crc_byte
    
End Function

Werkt perfect, zonder fouten en scheelt weer 1 byte overhead ;)

je kunt dacht ik ook domweg een parity byte instellen hoor...

Op 25 januari 2008 16:43:22 schreef Frederick E. Terman:
Nee, bij FSK slaat de "F" op het hoogfrequent.
Wat jij bedoelt zou dan AFSK heten - Audiofrequentie shift keying.

als ik dit lees:
http://en.wikipedia.org/wiki/Frequency-shift_keying

is het doodnormale fsk...

Take a parachute, and jump!

http://en.wikipedia.org/wiki/AFSK

Lees deze dan ook even door.

Bij FSK is de data op de carrier gemoduleerd.
Heel ruw voorbeeld. een 0 is 433MHz. een 1 434 MHz.

Bij AFSK maak je eerst een FSK signaal op audio level met bijvoorbeeld 1000 = 0 en 2000 is 1. Dit audio signaal moduleer je dan weer op 433MHz.

meten is weten, weten is meten, maar hoe kan je weten wat je allemaal moet meten en weten.