Wow, Phil. I'm going to have to consider this for Generation II (if I ever get around to it) of a phone-call interceptor I built in 2007 that controls who can ring my telephone. It detects incoming ring on the first cycle (faster than the telephone can detect it and ring); disconnects the phone line so the phone doesn't ring; waits for Caller ID between 1st & 2nd rings, then uses Caller ID to decide whether to connect the phone for subsequent rings. I think a Propeller could handle all that with, say, a 24LC512 or bigger to store the remembered information about callers. Generation I uses a modem to decode Caller ID, but very few modems can actually do that. Modems sold with the claim of handling Caller ID actually, in nearly every case, handle only Type 2 Caller ID (AKA call-waiting caller ID). Type 1 Caller ID, which occurs (in USA) between first & second rings, is supported by only two modems I have ever tested, out of hundreds that claim to support Caller ID. The two that support it are built-in modems in one model of Toshiba laptop, and one model of Dell laptop. Generation I runs on the Toshiba, and it's very nice to be able to exclude "Not Provided" and his business partner "Out of Area", along with various salesmen etc. I used to get two or three of these a day. They still call, but the phone doesn't ring and my frequent naps are undisturbed.
Your creation is a complete solution to the Caller ID problem!
Carl Hayes said...
Wow, Phil. I'm going to have to consider this for Generation II (if I ever get around to it) of a phone-call interceptor I built in 2007 that controls who can ring my telephone. It detects incoming ring on the first cycle (faster than the telephone can detect it and ring); disconnects the phone line so the phone doesn't ring; waits for Caller ID between 1st & 2nd rings, then uses Caller ID to decide whether to connect the phone for subsequent rings. I think a Propeller could handle all that with, say, a 24LC512 or bigger to store the remembered information about callers. Generation I uses a modem to decode Caller ID, but very few modems can actually do that. Modems sold with the claim of handling Caller ID actually, in nearly every case, handle only Type 2 Caller ID (AKA call-waiting caller ID). Type 1 Caller ID, which occurs (in USA) between first & second rings, is supported by only two modems I have ever tested, out of hundreds that claim to support Caller ID. The two that support it are built-in modems in one model of Toshiba laptop, and one model of Dell laptop. Generation I runs on the Toshiba, and it's very nice to be able to exclude "Not Provided" and his business partner "Out of Area", along with various salesmen etc. I used to get two or three of these a day. They still call, but the phone doesn't ring and my frequent naps are undisturbed.
Your creation is a complete solution to the Caller ID problem!
Before the national No-Call list, I'd have paid you handsomely for one of those devices, and I'm pretty sure that millions of other Americans would have as well.
I'm amazed at what Phil made here - it goes on my long list of Prop/Parallax things I need to find time to play around with, but I'm learning a lot just reading over the posts in this thread.
I got my Amateur Radio General ticket about two years ago (KC9KST), specifically so I could use Big Red Bee 433Mhz transmitters for locating my high power rockets. APRS is really interesting stuff as well.
Carl Hayes said...
Wow, Phil. I'm going to have to consider this for Generation II (if I ever get around to it) of a phone-call interceptor I built in 2007 that controls who can ring my telephone. It detects incoming ring on the first cycle (faster than the telephone can detect it and ring); disconnects the phone line so the phone doesn't ring; waits for Caller ID between 1st & 2nd rings, then uses Caller ID to decide whether to connect the phone for subsequent rings.
Hello Carl,
I'm interested in building such a thing myself as well. The telemarkers lately have become very adept at·ignoring the "do not call" registry (somehow every call these days is either a nonprofit company that is excluded, an offer by a company that I "already do business with" and is excluded, or someone that I "requested information from" (even though I didn't) and is excluded).
My particular take on this was going to be to implement enc28j60 ethernet and a·web server·on the prop and use that for configuration of the "do not receive" list. The enc28j60 designs are fairly easy and cheap to implement, although I would have to be a bit clever about dealing with tcp fragmentation of large web pages as I don't think the sample tcp stack handles it. This way the gadget could be populated with numbers by using any old browser in the house.
I would simply silence all of the ringers in my house and attach my own "ringer" to the prop. I don't care whether the answering machine catches the telemarketer (they often detect answering machines and hang up anyway). I'm just tired of the damn phone ringing while I'm trying to work.
By implementing my own "ringer" (prop audio output, amp, and a speaker), I could also implement selective ringing for different phone numbers. An SD card slot could allow custom ringtones.
Anyhow, it's been a long time since I've done any work interfacing with the telephone. I seem to remember some kind of decoupling transformer and some other bits needed to isolate the device from the phone line itself. Any information you can provide would be helpful, or if you'd like to collaborate that would be great.
I've built the setup as you described in the PDF document on 2 prop boards. and am not having joy. Hooking up a speaker, i hear those lovely tones, but I don't have a scope to see what they really look like. I've tried both the threshholding and Sigma-Delta demod designs. The 2 modems are direct connected (sig+gnd). My next step is to make sure I'm not overdriving if the audio is too hot. I am using your modem monitor and xmit programs to start. either way, the demo modem does not collect any input data.
Though I'm not looking for you to fix my specific problem can you suggest any areas to investigate? I plan to use the pair as a TNC from my RC plane to the ground station over the audio channel of my AV transmitter
And lastly , lest I forget - WOW!! What a great idea and implementation. Thank You Again Phil
Using a direct connection like you describe, you may not be getting an adequate audio level in the receiver. The output impedance from the transmit side is fairly high — designed to be used with a microphone or line-level connection to a transmitter. So I'm not sure it's capable of driving the receive circuit (whose input typically comes from a headphone/speaker output) directly. I'll have to try that here and see what it looks like on the scope.
Just to double-check: you're using the LP filter on the transmit side, then AC-coupling it to the divider on the receive side, right? Can you post both of your top-level (transmit and receive) programs?
You should get an even more robust response by using a larger-value coupling cap and larger-value divider resistors. The values here and in the docs were chosen so that all the caps and resistors were the same and were values easy to obtain from, say, Radio Shack. I got much better results in the direct prop-to-prop setup using 100K divider resistors on the receive side, since they load the transmitter less.
You will also need to adjust the modem parameters using the monitor program for best results. The default noise threshold and hysteresis are both too high, and the slicing level will need to be tweaked some.
Finally, one thing I discovered, since I was doing this experiment using multiple cogs in a single Prop, is that you need to make sure to allow time between starts of multiple Bell202_modem instances in different cogs. The reason is that, during startup (and only during startup), shared variables are being initialized in the DAT area of the hub, and if two starts are running simultaneously, they could conflict. I should probably modify the object to use locks, programmed to keep this from happening.
-Phil
_
Post Edited (Phil Pilgrim (PhiPi)) : 3/19/2009 9:15:10 PM GMT
I implemented the simplified hardwire connection you suggest along with the higher mdm.start_simple output levels settings and it came up like a champ.
Next I rushed a connection to my radio link and it also was solid. Of course this was a 12" rf link, but it worked just fine.
Next I need to play with the modem_monitor.exe program to understand how this should impact the setting for the link.
Alright, it looks like I'm the glutton for punishment. I've been working with this object as a base for an ax.25 PHY interface. Once that's done I'll probably gin up a KISS TNC out of it for verification. I think that it'd be appropriate to start new threads for those when I get there, but for the time being I've got coding to do.
Phil,
What did you write the signal quality monitor with? I'd like to make something like it that actually runs on linux (I can't get the monitor to work under Wine). Having something like that on my linux machine would make testing/debug easier for me, but I'd prefer not having to completely re-invent the wheel if possible. (I could probably fashion something, if need be, as the protocol isn't nasty...but as my last college advisor was know to say "I'm not lazy.......I'm efficient!")
The modem monitor was written in Perl/Tk. I've attached the source. It should be relatively easy to port it to Linux. The Windows-specific references deal with the serial ports, the registry (from which the available serial ports are obtained), and the clipboard.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 8/1/2009 8:05:51 PM GMT
Could have used this a few months ago when I was still feverishly working on my propcomp. I have a similar thing I am writing using dtmf and the goertzel algorithm, although so far i have only gotten it working on a pc.
I've started on a Goertzel object myself. 'Was hoping to use it for DTMF, and maybe even to take a stab at simple speech recognition. I haven't gotten very far with it yet, since real work keeps intruding. I would really like to do a Goertzel in continuous time, rather than in discrete chunks. There must be a way to do that by applying some sort of exponential decay to the coefficients...
Phil,
Thanks for the monitor sourcecode. I'll have a crack at running it on LINUX later today (more likely than not), as I'd like to get back outside before the weather craps itself again up here.
Somehow, I managed to miss this thread when it was first posted.
@Phil
Great work. This is one of the things I have been looking for to build a home pbx/call filter/answering machine.
@Carl, RvnPhnx, or anyone interested in such a project:
I tend to think of the device I want as a phone butler. My dream system would do the following:
1 - Based on the caller ID Perform one of the following: play a specific outgoing message, ring one or more extensions, take a message, hang up.
2 - Maintain a Caller ID list with actions for that caller ID
3 - Allow a caller ID to be added to the list with desired actions immediately after the call is finished.
4 - Take specific actions (take a message) if the caller ID is a blocked, unknown, or obviously invalid number.
I have neither the time or expertise to do all this in a reasonable time frame so I have been looking for the building blocks that would allow me to do so at a reasonable cost. I would also be willing to contribute to such a project and build or purchase the final product. As smbaker said in his post the telemarketers are finding ways around the "do not call list" so I think there would be a market for it.
Any interest?
PS - Carl, if you decide to go ahead with "Generation II" please let me know. I would definitely be interested.
This ought to have many applications in telephone systems. In the US (and perhaps other places too), Type 1 Caller ID is transmitted using the Bell 202 protocol. Received that way too, of course. Type 2 (call-waiting caller ID), of course, is wholly different.
On your schematic, it looks like the capacitors are polarized. Is this the case? I haven't been able to find an electrolytic that small. Will a ceramic or tantalum work?
Can anyone confirm these BackPack pins?
P12 = Rx Audio Feedback pin (not needed for threshold method?)
P16 = Rx Audio Sigma-Delta Input
P21 = Tx Autio Duty-Mode Output
P22 =·Switch to·Ground 0.1 cap (Phils has·cap grounded).
P23 = PTT Output (high going)
The BackPack uses 4.7uf instead of 0.1 for input and output caps.
Would this improve audo levels, or is this because they are doing Video on the Backpack?
If anyone has built this modem what method of demodulation did you use - thresholding·or delta-sigma?
Thanks,
CK (VE7DEP)
The circuit you've posted should work fine, with maybe a couple mods. The node labled P22 doesn't need to be a Propeller pin. You can simply ground it. In the input circuit, you can safely eliminate R5 and R6, and R4 and R5 R7 can have values a couple orders of magnitude higher. Their ratio wil be determined by the audio levels coming in from the receiver, and it may take some fiddling to accommodate the input dynamic range without clipping. (But even if clipping does occur, it's not the end of the world.) Mainly, however, you can use any Propeller pins you want for this circuit. You don't have to be guided in the least by the Backpack's pin allocation. The modem object's start_explicit method let's you establish any pin assignment you want.
-Phil
Edited to correspond to new schematic. CoronaKid had R5 listed twice in the one above, and I didn't catch it.
Post Edited (Phil Pilgrim (PhiPi)) : 5/4/2010 9:31:18 PM GMT
Phil Pilgrim (PhiPi) said...
The circuit you've posted should work fine, with maybe a couple mods. The node labled P22 doesn't need to be a Propeller pin. You can simply ground it. In the input circuit, you can safely eliminate R5 and R6, and R4 and R5 can have values a couple orders of magnitude higher. Their ratio wil be determined by the audio levels coming in from the receiver, and it may take some fiddling to accommodate the input dynamic range without clipping. (But even if clipping does occur, it's not the end of the world.) Mainly, however, you can use any Propeller pins you want for this circuit. You don't have to be guided in the least by the Backpack's pin allocation. The modem object's start_explicit method let's you establish any pin assignment you want.
-Phil
Thanks for your input Phil.
Ok on deleting P22 and grounding C1, but I'm confused·about the resistors.
Did you mean delete the caps C4 & C5 and raise the values of R5 & R6 to limit Rx Audio clipping?
I read over·your start_explicit method, which allows use of other I/O pins.·
That makes it more versitile.··We can take advantage of this when laying out the pc board.
The BackPack uses a 10Mhz crystal which Parallax does not sell.· Can we use the standard 5Mhz crystal?
Do you know the minimum Ram size needed for the code?
I assume that R1 & C1 form a RC low pass filter on the Duty Mode output.
The cutoff computes to 723Hz using Fc=1/2pi*R*C.· I thought it would be higher than 2200Hz??
Enclosed is jpg of my modem circuit in case anyone is interested, or wants to comment on it.
Cheers,
CK
Did you mean delete the caps C4 & C5 and raise the values of R5 & R6 to limit Rx Audio clipping?
No. I meant what I said (after editing ): delete R5 and R6. They're not needed to bias a sigma-delta ADC, only for thresholding when there's no feedback. C4 and C5 are necessary for sigma-delta, but R4 and R7 should be much larger. And definitely use pins for the sigma-delta that are closer together. You need to have the feedback resistor and caps adjacent to them.
The BackPack uses a 10Mhz crystal which Parallax does not sell. Can we use the standard 5Mhz crystal?
Yes. Just set the PLL to 16x instead of 8x.
The cutoff computes to 723Hz using Fc=1/2pi*R*C. I thought it would be higher than 2200Hz??
It's not a sharp cutoff, so those values will work. But if you're more comfortable with a shorter time constant, that's fine, too. The thing you don't want to do, of course, is overload the mic input, as that will cause clipping and degrade performance. You might want to take a look at your signal on the receiving end with a scope to get your levels set optimally.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 5/4/2010 9:31:44 PM GMT
Ok Phil,
I·modified the circuit·for sigma-delta ADC as per your suggestions. (Schematic below).
In case·I decide to change later to the threshold method I may leave traces for R5 & R6 as a backup.
I don't like it, but we can adjust the Rx Audio input level with the radios volume control, but the level to the Tx is fixed by the components.· We can increase·it by increasing C2 like they do in the BackPack (4.7uf), but what do we do if its too high?· We can't increase R1 as it will change Fo of the RC filter.· I would be nice to have a level control pot between C1 & C2, but another cap would be necessary to isolate it from the RC filter.
I can monitor the modulation level on my service monitor, Rx level with a scope and your Monitor exe.
Can't wait to try the code!
CK
Comments
Your creation is a complete solution to the Caller ID problem!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
I'm amazed at what Phil made here - it goes on my long list of Prop/Parallax things I need to find time to play around with, but I'm learning a lot just reading over the posts in this thread.
I got my Amateur Radio General ticket about two years ago (KC9KST), specifically so I could use Big Red Bee 433Mhz transmitters for locating my high power rockets. APRS is really interesting stuff as well.
I'm interested in building such a thing myself as well. The telemarkers lately have become very adept at·ignoring the "do not call" registry (somehow every call these days is either a nonprofit company that is excluded, an offer by a company that I "already do business with" and is excluded, or someone that I "requested information from" (even though I didn't) and is excluded).
My particular take on this was going to be to implement enc28j60 ethernet and a·web server·on the prop and use that for configuration of the "do not receive" list. The enc28j60 designs are fairly easy and cheap to implement, although I would have to be a bit clever about dealing with tcp fragmentation of large web pages as I don't think the sample tcp stack handles it. This way the gadget could be populated with numbers by using any old browser in the house.
I would simply silence all of the ringers in my house and attach my own "ringer" to the prop. I don't care whether the answering machine catches the telemarketer (they often detect answering machines and hang up anyway). I'm just tired of the damn phone ringing while I'm trying to work.
By implementing my own "ringer" (prop audio output, amp, and a speaker), I could also implement selective ringing for different phone numbers. An SD card slot could allow custom ringtones.
Anyhow, it's been a long time since I've done any work interfacing with the telephone. I seem to remember some kind of decoupling transformer and some other bits needed to isolate the device from the phone line itself. Any information you can provide would be helpful, or if you'd like to collaborate that would be great.
Scott
I've built the setup as you described in the PDF document on 2 prop boards. and am not having joy. Hooking up a speaker, i hear those lovely tones, but I don't have a scope to see what they really look like. I've tried both the threshholding and Sigma-Delta demod designs. The 2 modems are direct connected (sig+gnd). My next step is to make sure I'm not overdriving if the audio is too hot. I am using your modem monitor and xmit programs to start. either way, the demo modem does not collect any input data.
Though I'm not looking for you to fix my specific problem can you suggest any areas to investigate? I plan to use the pair as a TNC from my RC plane to the ground station over the audio channel of my AV transmitter
And lastly , lest I forget - WOW!! What a great idea and implementation. Thank You Again Phil
Paul
Using a direct connection like you describe, you may not be getting an adequate audio level in the receiver. The output impedance from the transmit side is fairly high — designed to be used with a microphone or line-level connection to a transmitter. So I'm not sure it's capable of driving the receive circuit (whose input typically comes from a headphone/speaker output) directly. I'll have to try that here and see what it looks like on the scope.
Just to double-check: you're using the LP filter on the transmit side, then AC-coupling it to the divider on the receive side, right? Can you post both of your top-level (transmit and receive) programs?
-Phil
As I suspected, the default settings won't give you an adequate audio level. Try this instead on the transmit side:
Here is the circuit I tested with:
You should get an even more robust response by using a larger-value coupling cap and larger-value divider resistors. The values here and in the docs were chosen so that all the caps and resistors were the same and were values easy to obtain from, say, Radio Shack. I got much better results in the direct prop-to-prop setup using 100K divider resistors on the receive side, since they load the transmitter less.
You will also need to adjust the modem parameters using the monitor program for best results. The default noise threshold and hysteresis are both too high, and the slicing level will need to be tweaked some.
Finally, one thing I discovered, since I was doing this experiment using multiple cogs in a single Prop, is that you need to make sure to allow time between starts of multiple Bell202_modem instances in different cogs. The reason is that, during startup (and only during startup), shared variables are being initialized in the DAT area of the hub, and if two starts are running simultaneously, they could conflict. I should probably modify the object to use locks, programmed to keep this from happening.
-Phil
_
Post Edited (Phil Pilgrim (PhiPi)) : 3/19/2009 9:15:10 PM GMT
I vote for you.
For example:
Demo of Caller-ID Signals :source code
Demo of DTMF Detection and Generation : source code
SX Software and Documentation:
www.parallax.com/tabid/460/Default.aspx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Hanno
I implemented the simplified hardwire connection you suggest along with the higher mdm.start_simple output levels settings and it came up like a champ.
Next I rushed a connection to my radio link and it also was solid. Of course this was a 12" rf link, but it worked just fine.
Next I need to play with the modem_monitor.exe program to understand how this should impact the setting for the link.
Thank you Thank you Thank you !
Paul
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
Wow, you've got your work cut out for you! Good luck with the project. I look forward to whatever you come up with!
-Phil
What did you write the signal quality monitor with? I'd like to make something like it that actually runs on linux (I can't get the monitor to work under Wine). Having something like that on my linux machine would make testing/debug easier for me, but I'd prefer not having to completely re-invent the wheel if possible. (I could probably fashion something, if need be, as the protocol isn't nasty...but as my last college advisor was know to say "I'm not lazy.......I'm efficient!")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The modem monitor was written in Perl/Tk. I've attached the source. It should be relatively easy to port it to Linux. The Windows-specific references deal with the serial ports, the registry (from which the available serial ports are obtained), and the clipboard.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 8/1/2009 8:05:51 PM GMT
Could have used this a few months ago when I was still feverishly working on my propcomp. I have a similar thing I am writing using dtmf and the goertzel algorithm, although so far i have only gotten it working on a pc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/
-Phil
Thanks for the monitor sourcecode. I'll have a crack at running it on LINUX later today (more likely than not), as I'd like to get back outside before the weather craps itself again up here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
@Phil
Great work. This is one of the things I have been looking for to build a home pbx/call filter/answering machine.
@Carl, RvnPhnx, or anyone interested in such a project:
I tend to think of the device I want as a phone butler. My dream system would do the following:
1 - Based on the caller ID Perform one of the following: play a specific outgoing message, ring one or more extensions, take a message, hang up.
2 - Maintain a Caller ID list with actions for that caller ID
3 - Allow a caller ID to be added to the list with desired actions immediately after the call is finished.
4 - Take specific actions (take a message) if the caller ID is a blocked, unknown, or obviously invalid number.
I have neither the time or expertise to do all this in a reasonable time frame so I have been looking for the building blocks that would allow me to do so at a reasonable cost. I would also be willing to contribute to such a project and build or purchase the final product. As smbaker said in his post the telemarketers are finding ways around the "do not call list" so I think there would be a market for it.
Any interest?
PS - Carl, if you decide to go ahead with "Generation II" please let me know. I would definitely be interested.
A most impressive job of work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
More to come.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
Can you provide the modified source?
Thanks,
Doug
Good going! Did you have to change much to get it to work?
-Phil
On your schematic, it looks like the capacitors are polarized. Is this the case? I haven't been able to find an electrolytic that small. Will a ceramic or tantalum work?
Thanks,
Doug
-Phil
Have a look here:
http://forums.parallax.com/forums/default.aspx?f=25&m=431050
Phil,
No, I didn't really have to change it too much. I did make some changes for convenience. I'm pretty sure I commented all of my changes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
I recently found·Phils excellent·Bell 202 modem object on the obex.· Now I want to build 2 units to experment·with·on the 2-meter ham band.
I'm·just·now·laying out the interface circuit using a basic prop set up and have a few questions.· (See photo below).
I've had a hard time figuring out what prop pins to use, so downloaded info on the Propeller BackPack to try to sort·out what pins go where??
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PropellerBackpackv1.0.pdf
See Pages 20 & 21.
Can anyone confirm these BackPack pins?
P12 = Rx Audio Feedback pin (not needed for threshold method?)
P16 = Rx Audio Sigma-Delta Input
P21 = Tx Autio Duty-Mode Output
P22 =·Switch to·Ground 0.1 cap (Phils has·cap grounded).
P23 = PTT Output (high going)
The BackPack uses 4.7uf instead of 0.1 for input and output caps.
Would this improve audo levels, or is this because they are doing Video on the Backpack?
If anyone has built this modem what method of demodulation did you use - thresholding·or delta-sigma?
Thanks,
CK (VE7DEP)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
________________________________
Work:www.vhf.ca··Play:www.Costalegre.ca
Post Edited (CoronaKid) : 5/2/2010 11:14:47 PM GMT
-Phil
Edited to correspond to new schematic. CoronaKid had R5 listed twice in the one above, and I didn't catch it.
Post Edited (Phil Pilgrim (PhiPi)) : 5/4/2010 9:31:18 PM GMT
Ok on deleting P22 and grounding C1, but I'm confused·about the resistors.
Did you mean delete the caps C4 & C5 and raise the values of R5 & R6 to limit Rx Audio clipping?
I read over·your start_explicit method, which allows use of other I/O pins.·
That makes it more versitile.··We can take advantage of this when laying out the pc board.
The BackPack uses a 10Mhz crystal which Parallax does not sell.· Can we use the standard 5Mhz crystal?
Do you know the minimum Ram size needed for the code?
I assume that R1 & C1 form a RC low pass filter on the Duty Mode output.
The cutoff computes to 723Hz using Fc=1/2pi*R*C.· I thought it would be higher than 2200Hz??
Enclosed is jpg of my modem circuit in case anyone is interested, or wants to comment on it.
Cheers,
CK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
________________________________
Work:www.vhf.ca··Play:www.Costalegre.ca
No. I meant what I said (after editing
The BackPack uses a 10Mhz crystal which Parallax does not sell. Can we use the standard 5Mhz crystal?
Yes. Just set the PLL to 16x instead of 8x.
The cutoff computes to 723Hz using Fc=1/2pi*R*C. I thought it would be higher than 2200Hz??
It's not a sharp cutoff, so those values will work. But if you're more comfortable with a shorter time constant, that's fine, too. The thing you don't want to do, of course, is overload the mic input, as that will cause clipping and degrade performance. You might want to take a look at your signal on the receiving end with a scope to get your levels set optimally.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 5/4/2010 9:31:44 PM GMT
I·modified the circuit·for sigma-delta ADC as per your suggestions. (Schematic below).
In case·I decide to change later to the threshold method I may leave traces for R5 & R6 as a backup.
I don't like it, but we can adjust the Rx Audio input level with the radios volume control, but the level to the Tx is fixed by the components.· We can increase·it by increasing C2 like they do in the BackPack (4.7uf), but what do we do if its too high?· We can't increase R1 as it will change Fo of the RC filter.· I would be nice to have a level control pot between C1 & C2, but another cap would be necessary to isolate it from the RC filter.
I can monitor the modulation level on my service monitor, Rx level with a scope and your Monitor exe.
Can't wait to try the code!
CK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
________________________________
Work:www.vhf.ca··Play:www.Costalegre.ca