This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

R/C reciever with TM4C123G



Hello everyone!

I'm working on a hobby project and one of my goals is to read hobby RC reciever. It sends a PWM pulse to specific pin for each channel. I got the code working perfect when it was all in one file (main.c). But sice it's more organised to have more files, I decided to seperate functions for reading signal, functions that take care of time ( all od these are interrupts) into RX.c and Time.c .

And now the problem occurs. All of the sudden nothing works anymore. The code is the same as it was before. So I had to add function that returns the current time ( micros() )

RX.c :

#include "Time.h"

#include "RX.h"

void RXChannel(){


	IntStatus = GPIOIntStatus(GPIO_PORTA_BASE, true); // GET INTERRUPT STATUS ( ON WHICH PINS INTERRUPT HAPPENED)
	GPIOIntClear(GPIO_PORTA_BASE, IntStatus);         // CLEAR INT FLAG
	//long long x = micros();


	///////////        AUX1       ///////////////
	if((IntStatus & GPIO_INT_PIN_5) == GPIO_INT_PIN_5) //  DID INTERRUPT OCCURED ON PIN A5?
	{
		value = GPIOPinRead(GPIO_PORTA_BASE, GPIO_PIN_5);
		if(value  == GPIO_PIN_5) // IS PIN A5 HIGH?
		{
			RisingEdge1 = micros();
		}
		else if(value == 0) // IS PIN LOW?
		{
			uint32_t i = micros();
			AUX1 = i - RisingEdge1;

		}
	}
}


And time.c :

static volatile uint32_t microsec;

static void SysTickIntHandler(void){
	microsec++;
}

void Delay(uint32_t delay){
	volatile long i = microsec;
	while((microsec-i) < delay);
}

void initTime()
{
	  SysTickPeriodSet(79);
	  SysTickIntRegister(SysTickIntHandler);
	  SysTickIntEnable();
	  SysTickEnable();
}


uint32_t micros(void) {
	return microsec;
}

After hours of debugging, I forgot to turn on transmitter ( so, if transmitter is off, reciever should not send any signal to pins) and I realized that code still acts as the signal has been recieved. All IF statements passed. I am realy desperate here, so any help would be appriciated.

Thanks!

Regards, Kristjan

  • Hello Kristjan,

    Are you sure there is no other RC transmitted in the vicinity that is till sending a signal? Connect an scope on the pin to see if there is a signal still being received?

    Regards
    Amit
  • Hi Amit,

    Good thought (another RC Xmtr) yet there are more possibilities:

    • With the RX Xmtr "Off" might the Receive Input circuitry be too, "high impedance for the MCU input" to which Rcvr circuitry connects?
    • Beyond "other" RC Xmtrs - what about cell, ham radio, or local (commercial) broadcast stations?
    • Presence of "likely candidate" Noise/RF sources such as Power Circuits, Switching Power supplies, etc.

    Poster must insure that his "connected" MCU's Input does "RTZ."   (Return to Zero - where "zero" may be a logic high or low - depending upon external factors)

    Once the input is judged "good" - then the code-stepping can commence in earnest...

  • I have currently no scope at disposal, however, if I use old code ( everything in one main.c) it works perfectly.. Is there perhaps something wrong with how I use time functions and return functions (micros()) ?

    Regards,
    Kristjan
  • Update: old code works only when I connect transmitter to reviecer and power them on. Pulse lenght is 1500 us, as it should be.
    However, when I disconnect transmitter (so there should be no signal coming from reciever to TM4C) pulse lenght jumps to 7000 us. Correct lenght should be 0.
    Is it possible that reciever is broken?
  • Hello Kristjan,

    A scope probe on the receiver to TM4C must first confirm the observation of 7000us of pulse width. It could be possible that the receiver with the old code and transmitter switched off, is catching stray IR signals off of some "transmitter". Note that IR is pretty notorious on reflections, so a strong remote transmitter may be the source of your worries.

    Regards
    Amit
  • Are you sure the length should be zero?

    It makes sense for an R/C receiver to produce a failsafe output. For a output expected to drive servos the obvious failsafe output would be a PWM at either 0 or 50% but still a PWM.

    Robert
  • Amit, yes that may be the case, but the problem is that before I updated the code, it worked good. I didn't have any problems... also, I connected reciever to ESC controller and brushless motor and it works fine.

    Robert, so you are saying that reciever has build in failsafe, and when I disconnect transmitter it goes into failsafe mode?

    Thanks for help!
  • Robert, I just checked transmitter settings and all failsafe functions are turned off. So that is not the case.
    I will try to get a oscilloscope somewhere and test signals.
  • Ok so I figured it out. Turns out I had to connect ground from reciever to controller. I just don't understand why, sice it worked without that just fine.
    Thanks everyone for help, it helped me to expand my knowledge :)
  • Perhaps "lesson-learned" here: Changing code, and powering/connections - all together - is MAJOR violation of KISS! (One and ONLY One Change at a time - and then immediate inspection, test/verify!)

    Juggling more than one "Running Chainsaw" does not insure, "Full complement of hands/fingers (head?)"
  • Failsafe would be a receiver function, not a transmitter function.

    Robert
  • kristjan berce said:
    Turns out I had to connect ground from reciever to controller. I just don't understand why,

    How else were you expecting the micro to be able to distinguish high from low?

    kristjan berce said:
    it worked without that just fine.

    Consider this a lesson that sometime even when the hardware is not correct it will appear to work under limited circumstances.  Also why testing is generally insufficient to produce a correct design.

    Robert

  • Robert Adsett said:
    ...testing is generally insufficient to produce a correct design.

    Agreed Robert - and it is only testing which is: properly conceived, implemented, and fully sufficient - under a broad range of conditions (some even judged to be "unlikely" (until they occur in the field!) ) which may "catch" a flawed design.

    Full, proper, "sweat the details (all the details)" design up front proves best path to a correct design.

    Testing - even extensive testing - cannot build quality & soundness (into) a design.   Quality & correctness most often result from "extreme thoroughness, care, & team-effort - early - and throughout" - the entire design process.   

    All too often - "imperfect" testing (appears) to convey "correctness."    Deeper reality is that the "test methodology & provisioning" must be part of the initial design process - must be highly valued, committed to - and properly implemented.