sending FAX via PIC

[temtronic]

Have a client with odd request. He needs to replace a custom PC with fax card system. Only serial data comes from his host(msg with embedded customer account info).
One solution is to use another PC/modem/cut code with Delphi... qb4.5,..big,$$$,not a PIC !

My preferred solution would be a PIC to receive the serial data and send it to an external FaxModem. PIC would listen for msg, parse the acnt, lookup phone number and send msg.
External modems are $20, PIC board <$50, small size, cheap, reliable.

Has anyone connected to a FAXmodem using the AT command set?
I know SMS is today's way...but client needs to goto dialup real fax machines, msgs longer than 255 bytes.

Thanks for any help

[gpsmikey]

The closest I can come off hand was an article about 10-12 years back in Circuit Cellar by Edward Cheung on interfacing ISA ethernet cards to a PIC that might prove helpful. Not quite the same, but perhaps some ideas there.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[FvM]

The question isn't completely clear. What's the message format? Do you have an already encoded fax data stream?
If it's plain text, sending to fax involves printing it by a bitmap font of your choice and convert the bitmap data to
a compressed CCITT T.4 fax format (using huffman encoding). There are only a few AT commands needed for the transaction.

[temtronic]

It's straight ASCII from the computer.
Right now the JTFAX card does all the conversion. It was a very special card made 30 years ago, NOTHING exists to replace it, I've searched for 10 years. NO 'regular' PC faxmodem card will do it, so I thought use an external serial modem.

I have the CCInk mags from day one, so I remember the ISA article with the 16F877, good idea but overly complicated HW.
That's why I figured a PIC as 'glue' to translate the ASCII serial data into FAX 'lingo' would be a slick method.

I knew it wouldn't be as simple as I hoped.....sigh

FvM, I'd appreciate a link to the commands, maybe an example in any language so I can convert to PIC C... google seems to send me into 'canned software', not 'board level info'....

[FvM]

I can send you a Borland Pascal example project, that does the text print, T4 enconding and modem control.
The AT fax commands are for an old V34 Rockwell modem chipset, but I guess, you can find a replacement, if necessary.

[Ttelmah]

Realistically, you would need a PIC 2with more RAM than the 877. Fax is a 'scanline' image of the intended data, just as if it had been printed out, then scanned (by the fax). A single line of characters, will involve perhaps 7 to 8000 'points'....
Any PC can do this, and the core software comes with all the latter Windows OS's, and similar code is also available for Linux.
If it is a 'one off', this could be done in a few hours, by using one of the small 'matchbox' embedded PC's, a modem, and a few lines of code in Linux or Windows (in Windows for example, you would just write the incoming text to a .txt document, set this to automatically line wrap (assuming the text is not already set up with a sensible line length), then use the 'print to fax' option. This could all potentially by done in VBS.
It could be done in a PIC, but you'd be talking a significant amount of code. You'd have to choose one that has enough RAM, to hold a few dozen 'lines' of the fax. Arrange these as some form of 'line FIFO', then have in ROM, a character map for all the incoming characters, and as these arrive, 'build' the scanlines. Once you reach the end of a line of text, you can start sending the image lines from the start of the buffer, as you carry on converting the data. the actual AT commands to control the modem, would be the smallest part of the work involved. Software would take a few days to code....

Best Wishes

[FvM]

[Ttelmah]

Except that to be reasonably efficient in building the outgoing image, you are going to want to build all the lines for the single line of text at once, or you are going to have to scan the same line repeatedly (and therefore hold it in RAM longer). Either way, more RAM.

Best Wishes

[dbotkin]

Seriously. I've been accused of swatting flies with artillery before, but you're shooting at pheasants with a slingshot. :) There is a dead simple solution to this problem. HylaFAX. You can send FAXes anywhere, with any FAX modem, from ASCII, TIFF, PostScript, and PDF source. You can also do email-to-FAX, set up a Windows (Samba) shared printer that will send a FAX, send messages to text pagers... there's very little that HylaFAX won't do, and it's completely free and open source.

It runs perfectly well on whatever flavor of Linux or BSD you care to run. If your customer doesn't want to learn to manage a *NIX machine, set him up a little "appliance" box that he can send stuff to (print jobs, email, even ASCII text over a serial cable). It will run indefinitely without anyone touching it if it's set up right. Or, you can put it on his network and log into it remotely for updates and maintenance -- though for a single application box like this, it's really not needed.

PICS are great for a LOT of things, but it's not the right tool for this job. If the job includes anything to do with FAX, HylaFAX is the right tool.

[Ttelmah]

Yes.
This was my 'en passant' line about Linux.
One of the tiny 'headless' industrial PC's, or (cheaper), an old laptop, with the display switched off (if lucky, you may well find one that already has the modem), and "Robert's your father's brother".
I'd say this could easily be got working in an afternoon, while writing the PIC version will take an age relatively, and by the time you have had a board made, cost quite a bit more....

Best Wishes

[bkamen]

I would also recommend looking into Hylafax.... it's like the swiss army knife of fax tools...

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[FvM]

I'm a bit surprized about the persistent arguments for using a PC for a simple application, that can be easily performed by a PIC18. I don't know, if it's an option for temtronic, but I know a lot of embedded applications, where it surely isn't. There's by the way a lot of alarm modems on the market, that besides SMS, E-Mail, voice and dial-in data connection are able to send faxes.

Referring to a technical detail:

[dbotkin]

Look at the development time alone. In half a day you could have a Linux/HylaFAX solution set up and working fine, using old PC hardware at no net new cost -- even a 486 would do the job nicely, so whatever discarded hardware is available would work fine. I know, becuase I ran HylaFAX (along with many other functions) on a 486 for a couple of years, handling FAX as well as text and numeric paging.

You could, with minimal extra time and effort, even do it on a diskless PC booting from a CD-ROM drive (under $20 new). Now you can replace the PC when it breaks with whatever slightly newer discarded hardware you have available, with no hassle. Throw the CD in a new system and off you go. If it hangs or has problems, just hit the reset button.

Contrast that to a PIC solution. How many hours of development time do you really think it would take for someone to produce a working PIC device that will send a FAX? And then you're going to have to produce at least one completed example, meaning either a custom PCB or a lot of cut/strip/solder or wire wrap. By the time you're done, you will more than likely spend more money AND more time on the PIC solution.

I'm all in favor of using PICs where they make sense. In this situation, it doesn't appear to make sense to me. If you needed a bunch of them, maybe... but for a one-off, I don't think so.

[Ttelmah]

It isn't a problem, but needs more RAM.
I was arguing that to do it with a PIC, without the code getting too complex, you would need a reasonably large amount of RAM. Rescanning the line multiple times, decreases the RAM needed for the output buffer, but increases the amount needed for the input buffer. Either way, reasonable amounts of storage are involved.

The argument for using a PC, is dependant on how many units are involved. Seriously, this could be put together using a shell script, in Linux, in probably under a dozen lines of code. Even starting from scratch, assembling a machine, putting a small Linux together, and writing the code, could be done in a very few hours. To write it on a PIC, would be several days work, plus the design of the PCB, and getting these made. For a one off, up to a few off, the PC solution will be cheaper, and be produceable in far less time. Seriously, have you realised just how cheap a embedded PC is now?. You can get complete units under $100, even if you add a modem, costs are very small. For the one off though, a slightly old laptop, is often a 'give away' item now (we gave fifty recently to a local school, only three years old, and each could have done this job easily).

However if the market is likely to be hundreds off, the development cost of a PIC solution, could then be justified, by the final production cost being cheaper _once a reasonable quantity is involved_.

Best Wishes

[FvM]

Everything has been said, already, I think. Except this: The "embedded PC is cheaper" argument applies
to about 90% of the applications, that are usually discussed at CCS forum.