| View previous topic :: View next topic |
| Author |
Message |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
 Posted: Fri May 04, 2012 6:37 am |
 |
|
Hi,
The real problem is that you are trying to test too many things at once. The only reliable means to troubleshoot a project like this is to break it up into pieces, test them all individually, and then put them all together to achieve the final goal.
On the transmitter side, are you absolutely sure what is being transmitted? I doubt it. You are reading a 10 bit value, and then stuffing it into an 8 bit variable, and then transmitting a single byte of data. Is that really what you want to do?
On the receiver side, are you absolutely sure sure what is being received? Are you sure it's the same as what is being transmitted? I doubt it. Are you absolutely sure your display routines are working correctly, and will correctly display the data that is received? I doubt it.
You *think* this is an IR communications problem, and it may be, but I don't think there is any certainty in the transmit code, the receive code, or the display code. Separate them, and solve them individually, and learn to properly troubleshoot your code this way, or the likelihood that you will ever have any success with more complex projects is nil.
BTW, a great way to troubleshoot your code is to simply assign a spare pin to output diagnostic serial data. Connected thru a MAX232 IC to your PC, and you'll be able to actually see what's going on in your code rather than guessing.
John |
|
 |
Diogene_Niyigena
Joined: 21 Apr 2012
Posts: 12
|
|
| Posted: Mon May 28, 2012 5:10 pm |
|
|
Hi everybody!
All this time I've been working on this project but till now there is no remarkable improvement from my last post. First of all I'd like to let you know that it's not easy for me to find the MAX 232 to send my data on a PC. Which means that my problem is still remaining the same. But before I give up with this project I want to let you know what I am thinking is the cause of the problem:
=>
I am using BC 337 transistors for multiplexing the two seven segments which I think it may cause a delay in the display, hence some data is lost at a given time.
For this, I realized that at least a multiplexing time of 10ms is required for each transistor driving one seven segment.This implies a 20 ms for a two digits display. Beyond 20 ms (40 ms in total) the segments are messed up.
This made me think that maybe 7-segments displays are not suitable for this project because it seems difficult to synchronize the transmission rate with the multiplexing time. (I am using 12 MHZ oscillators).
Here I remind you that at the transmitter side the display is really perfect only the display of the receiver is not stable where the real display is appearing and disappear as if no data is being sent at that short time and so on.
Am I wrong ? Can anyone suggest me any other idea?
Thx |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Tue May 29, 2012 6:55 am |
|
|
Hi,
You've had a lot of useful suggestions about how to understand/solve your problem, yet you seem to be more comfortable plowing ahead with the same flawed troubleshooting/guessing techniques that have failed you so far.
Almost without exception, I dedicate one pin on every PIC project I develop for serial diagnostics. I have a small TTL-to-Serial converter board that allows me to connect this pin to my PC and read the diagnostic messages I've added to my code. I can tell you that occasionally this diagnostic data is worth its weight in gold! I recently used a modified version of a subroutine I've used in many projects over ten years, and it wasn't until I looked at the diagnostic data that I was generating that I realized the modification I made had an unintended consequence...... Without that data, I would have been frustrated for a long time!!
PM me your mailing address, and I'll send you a couple of MAX232 IC's and the components you need to make your own diagnostic adapter.
John |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Tue May 29, 2012 6:56 am |
|
|
| Quote: |
Am I wrong ? Can anyone suggest me any other idea?
|
Simple answers. Yes and yes.
You've been given loads of hints on this and you're still not really understanding how to tackle the problem in a logical ordered fashion.
The BC337s are not your real problem.
MAX232 is an inverter / voltage level shifter. If you can't get one, then either use an earlier generation TTL to RS232 shifter, or build your own. Looking at your data signals on a PC makes life SO much easier.
| Quote: | For this, I realized that at least a multiplexing time of 10ms is required for each transistor driving one seven segment.This implies a 20 ms for a two digits display. Beyond 20 ms (40 ms in total) the segments are messed up.
This made me think that maybe 7-segments displays are not suitable for this project because it seems difficult to synchronize the transmission rate with the multiplexing time. (I am using 12 MHZ oscillators).
|
10ms per digit is the MAXIMUM time I'd use for multiplexing a two digit display (less time for more digits).
Your receiver strategy is fundamentally flawed.
You're using delay_ms(xx) to mux the display. You've already been told this is a recipe for disaster. Delay_ms(xx) is locking up your PIC, so that it can't do anything else, hence your receiver is MISSING the incoming data whilst it twiddles it thumbs.
Your PICs got several built in hardware timers and a UART. Use them. That way your PIC will be able to keep pace with everything that's going on and have spare capacity.
It would help if you showed us some sort of schematic so that we can relate your code to your hardware.
Mike
EDIT Take up ezflyr's generous offer. We were both posting at the same time. |
|
|
Diogene_Niyigena
Joined: 21 Apr 2012
Posts: 12
|
| Want to use timers |
| Posted: Sun Jun 03, 2012 4:49 pm |
|
|
Thx everybody and sorry for my endless questions,
I want to try timers instead of delays (in the receiving code) but i can't figure out how to use them. I searched the ccs c manual but i am not being able to use timers for 10 ms delays to multiplex the 7 segments displays. Can you please tell me how to proceed that i can be able to multiplex my 7-segments displays without using those delays as they lock up the MCU?
Thx |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Mon Jun 04, 2012 4:47 pm |
|
|
I showed kamillas how to do it on his topic "7 segment time" in February this year.
In view of the responses I got, I suggest that you look it up for yourself rather than letting me doing all the work.
Mike
http://www.ccsinfo.com/forum/viewtopic.php?t=47508 |
|
|
Diogene_Niyigena
Joined: 21 Apr 2012
Posts: 12
|
|
| Posted: Wed Jun 06, 2012 3:47 pm |
|
|
Hello Mike,
I edited your code as follows:
| Code: |
/*
**************************************************************************************
** Multiplexes temperature value on two seven segment displays
**
** Digits are updated @ ~700Hz in isr
**
** Main spends time collecting temperature data at its own pace
**
**************************************************************************************
*/
#include <16F877A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#FUSES NOWRT
//Program memory not write protected
#use delay(clock=12000000)
#use rs 232(baud=2400,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS,PARITY=N)
// Declare constants & variables
int tab[10] = {0xC0,0xf9,0xa4,0xb0,0x99,0x92,0x82,0xf8,0x80,0x90}; // segment table, symbols 0 - 9
int temperature;
byte temp_unit , temp_ten ; // temperature tens & units
int digit; // current active display digit index
// main()
//
// sets up timer0 for interrupts.
//
// in a loop
// forces temperature value to advance twice per second
// confirms temperature display multiplex is working
//
// when happy that multiplex is working:-
// remove delay_ms(500).
// replace temperature advance with read_18B20() function.
//
// *****************************************************************************************
void main()
{
setup_timer_0(RTCC_DIV_16 | RTCC_INTERNAL | RTCC_8_BIT); // timer 0 interrupts @~700Hz
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);
While (TRUE)
{
temperature = getc();
//while (temperature < 100 )
temp_unit = temperature %10;
temp_ten = temperature /10;
// delay_ms( 500 );
// temperature++;
}
}
// *****************************************************************************************
// timer0 interrupt isr.
// selects new digit to light.
// turn last digit off
// sets new digit segments
// turn new digit on
// exit isr
// *****************************************************************************************
#int_timer0
void segment_mux_isr()
{
digit++; // advance to next digit
digit%=2; // reset to 0 if > 1
if (!digit) // test for digit 0
{
OUTPUT_d(0b00000000) ; // digit 0 is units i.e. 10^0
OUTPUT_b(tab[temp_unit]) ;
OUTPUT_d(0b00000001) ;
}
else
{
OUTPUT_d(0b00000000) ; // digit 1 is tens i.e. 10^1
OUTPUT_b(tab[temp_ten]);
OUTPUT_d(0b00000010);
}
}
// *****************************************************************************************
|
Now the segments are not any longer flickering but still it seems like the receiver is losing some data because the real display is showing and disappear and so on. Is there anything I can improve from this code? |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Wed Jun 06, 2012 4:31 pm |
|
|
Like ezflyr asked some time ago.
On the transmitter side, are you absolutely sure what is being transmitted?
Maybe you could test without the IR link. Simply connect the TX of the transmitter directly to the RX of the reciever.
Life would be more straight forward if you were trasmitting ASCII characters. Then you could monitor on a PC.
I had thought that you could be getting a null from the UART, if the receive buffer was empty. On reading the CCS manual, getc() waits for data, so that shouldn't be the problem.
It's down to testing, testing and more testing. You have been given loads of hints!
Mike |
|
|
Diogene_Niyigena
Joined: 21 Apr 2012
Posts: 12
|
| IR problem |
| Posted: Sat Jun 09, 2012 5:49 am |
|
|
Thx everybody for your time. The problem is not yet solved but now i think it is not a matter of multiplexing time or code either for transmitter or receiver. I connected the TX pin of the transmitter directly to the RX pin of the receiver and the displays are displaying the same value. I think the problem is my IR receiver (the HS 0038 A2) or the hardware in general or maybe the way i am modulating. I'll try to look for another part and see what it gives.
Thx again. |
|
|
SuperDave
Joined: 22 May 2008
Posts: 63
Location: Madison, TN
|
|
| Posted: Sat Jun 09, 2012 7:55 am |
|
|
TV remote IR receivers are a good cheap way to send 'wireless' data but there are lots of hidden pieces that are not intuitively obvious.
1. The 38kHz (there are receivers with other expected frequencies) is a carrier which expects to be amplitude modulated on/off, so your transmitter has to put out a 38kHz pulse train and then no pulses with some coding scheme to send the data.
2. A good receiver module will then output a digital signal that is high when pulses are present and low when they aren't.
3. HOWEVER, the on/off times can't be too fast because the PLL in the receiver has a finite lock up time depending on the design.
4. AND, the on/off times can't be too slow because the AGC in most (but not all) detectors considers long on times as room lighting and effectively ignores them.
5. The transmitter IR spectrum should match the receiver IR spectrum.
6. The receiver should be in a 'dark room'. This is not necessary or even useful for the transmitter. The 'dark room' can be a simple tube or whatever works for your application but it helps to get rid of off axis light if you don't need wide acceptance range. |
|
|
SuperDave
Joined: 22 May 2008
Posts: 63
Location: Madison, TN
|
|
| Posted: Sat Jun 09, 2012 8:01 am |
|
|
| Oh....and you cannot directly drive the IR Led from the microcontroller. You MUST have a resistor in series to limit the current to about 20mA or use a transistor driver with a base resistor or a FET which can be driven directly. If you drive a LED straight, the current will be limited by the micro to about 25mA, but the 'read/modify/write' will be thoroughly screwed up by the LED clamping the voltage to a fairly low value. |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Sun Jun 10, 2012 2:08 am |
|
|
OK. So, eventually you've got round to proving that the problem is the IR link.
Temtronic suggested somthing similar over a week ago. Test the IR link on its own. Send a short repeating string of characters, with a space, from the TX to the RX. Get access to a 'scope, look at both transmitted & received waveforms together. (The space will allow you to sync the 'scope.) They should show you what is going on, and enable you to work out a strategy for solving the remaining problem.
Mike |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
