[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internet on the Go: the PC3K and a mobile phone...
Hi Sven
I thought allready i'd seen it somewhere but this morning I came across it again.
You wondered wether somebody had ever tried a IR port on the PC3000,
so in a few newsgroups you can find this message from Gerard van Draanen
Maybe you can do something with it
Regards
Leo
From: Gerard van Draanen (gerard@xxxxxxxxxxxx)
Subject: RFC -- Input IR-RC on a (Sharp PC300) PC ; remote control
Newsgroups: comp.sys.palmtops, alt.comp.hardware.homebuilt, comp.dcom.modems, comp.os.msdos.programmer, comp.sys.handhelds, comp.sys.ibm.pc.hardware.comm, sci.electronics
View: Complete Thread (2 articles) | Original Format
Date: 1996/03/25
Hello Netters,
I'm currently working on getting my Sharp PC3000 Handheld computer to be able
to send and receive via an IR interface.
TX/RX for (regular) DataComm....
CTS/RI for Bitstream information.
I could use a little help on a couple of subjects.....
- How to properly setup some electronics around the IR-receiver, for it to
be able to capture ~40 kHz IR signals into binary (+or -10V ) signals
suitable for detection on a PC's rs232 port.
- How to optimize the (sample) assembly language program I made, so it
becomes more useful...
And maybe.... one of you people has done all this before... If so, I'd be
glad to hear about the availability of such 'sample' software.
The idea, is that I'm doing a 'raw' sampling and storing, with oversampling
to be able to repeat the IR signal through output across a IR-Led in
parallel to the PC's speaker.
Here's the information, and analysis so-far.
Feel free to add to this, or to give me pointers on possible assy language
improvements.....
Let's get this stuff going... my preliminary test are very hopeful..
Thanks in advance for your further input,
Gerard.
=================== _____ Mngr.Tech.Autom. / ==============================
Gerard van Draanen. / _ _ _, __ _, __/ How come, after all books read
gerard@xxxxxxxxxxxx / / /-' / /_/ / /_/ You still can't go by the book
=================== ~~~~ `~ ~ ~ ~ ~ ==============================
--
Gerard van Draanen -- IR.TXT -- -1-
'960308 '960325
Wireless communication between (PC) equipment is being used more and more.
A number of new PC's are supplied standard with IRDA interface.
There's a possibility, with relavively simple H/W adjustment to create such
a communication link without cable.
Esp. in an industrial environment, an IR communication can be an alternative
to reduce on cabling (and installation) cost in a couple of situations.
Simply put, the wireless comm. comes down to an IR-led & IR-receiver.
In some cases, 1-way traffic will suffice.
(Remote-Control of auxillary equipment, displays, Barcode-lezers, TVs etc. )
A sender/receiver thus has 2 specific types of input/output:
- Bitstream ... Data to be sampled without further interpretation
. User assigns 'logical meaning' to a sample
.. Sample can be repeated as output
-- on a different location
-- on a different time
to get a reaction from equipment, equal to a situation of
sending the original sample directly.
.. Multiple samples can be combinded, or timed, to make more
more complicatied input/output situations.
- Datacomm ... (ASCII) data is transferred, WITH its usual timing / meaning.
There are a couple of ways to go about sending and receiving the signals...
- Dedicated external Harware, capable of 'understanding' bitstream samples
- Non-dedicated hardware, but extensive s/w to 'understand' the sample
- A 'stupid' simple device, giving bitstream to be repeated
I'll go for the 'stupid' device... I don't want to add external h/w to
achieve my intended purpose here...
Basic possibilities are IR-Led in parallel to speaker
or on RTS / DTR output of Serieal port
and/or TX output of Serial port
or on one of the 'OUT' bits on the Parallel port
IR-receiver or RI/ DCD/ CTS/ DSR from Serieel poort
and/or on RX input of Serial port.
or on one of the 'IN' bits on the Parallel port.
A basic need, is to create a fixed sample rate, not related to PC speed.
The baudrate generator in a PC can function perfectly for this..
But... the sample rate needs to be in the 80--120kHz range (oversampling), and
that needs a bit of extra thought on the PC's end.
For Datatcomm, using TX/RX on the serial port should suffice, without further
software adjustments. This will enable operation similar to a 3-wire connection.
Note:One (1) sender can reach multiple receivers
The TX/RX comm can not be used for a Bitstream, since the 'framing' information
will interfere with the signal to be sent.
The original equipment will not have facilities to strip or add these bits.
In the 'BitStream' case, signals from RTS (out) and RI (in) pins are preferred.
/O.
Gerard van Draanen -- IR.TXT -- -2-
As background information I've studied a number of magazines and books.
I don't have (any) understanding of the IR-RC basics, other than what I've
read from these articles...
References:
Ct magazine Nr7 + Nr8 '91
Elektuur 4-'94 en 11-'94 Subj. IR-RC op PC, en Philips RC5 codes
And for some detail info on the PC's serial port and h/w configuration:
Crafting C tools for the IBM PCs ISBN: 0-13-188418-2 025
(Joe Campbell, Prentice hall)
The IBM PC & PS/2 ISBN: 1-55615-131-4
(Peter Norton, Microsoft Press)
Note:Rohm Electronics GmbH; Karl-Arnold-Str 15;47877 Willich-Munchheide;
Duitsland... Tel +49-2154-9210 (Fax : +49-21544-9214-00)
Has an IR (IrDA1.0) compact IC for Send/Rcv+Modulatie: RPM 800CB
2k4 t/m 115k2 Transfer rate in mini housing..(12*5.5*4.5 mm)
An IR-RC signal is generally made-up out of a modulated base frequency in
31, 38, or 40 kHz range. '0' & '1's are then 'Gated' on the base frequency.
The setup of the Data-signal is...
---init----[pause1]___data_____
or ---init----[pause1]...header...[pause2]___data___[pause3]
the possibly repeating part is : ..................
So, there is a difference in 'one-time' signals and signals being repeated
until the 'button' is released. The signal content is Factory specific.
Numerous codes, combinations, timings etc. exist for all the various
manufacturers.
==========
Some background info on the Alarm timer, Serial port and Sound/Speaker:
==========
Alarm Interrupt (vector 4A) is at 0:128 in byte-reversed format
v.b. PC3k: 02 2f C4 25
So, its a reference to an alarm-handling function at 25C4:2F02
Such a routine can be used to -timed- send a specific IR-RC code.
Further interaction with this service requires some further study.
A possible base for time can be the built-in
8253 programmable interval timer:
Ch-0 = 18.2/sec PC clock timer output
Ch-1 = Ram-refresh
Ch-2 = Speaker frequency <== Basic freq via programmable devider.
Ch-3 = ?, often via NMI
Ch-2 can be used for Sound-generation (and -thus- for IR led control)
8253-5 Input signal is 1.19xxx MHz, output is via Devider
Programing the Devider:
OUT 43, B6 <- Prepare 8253 to accept devider
OUT 42, 0A <- Low order
OUT 42, 00 <- High order
Will giva ca. 100kHz signal to Sound-Amp
That signal .... we should be able to pick up
OUT43, OUT42 8253-5 --> Ch-2 ---->
--> Speaker
OUT 61, xx -->
Bit 0= pulses on Ch-2 to speaker
Bit 1= 1of0 setting of Speaker bit
INP 61 AND FC (As to avoid damaging other INP61 bits)
... IF it would be possible to READ the current state of the Ch-2 status,
THEN that state could function as a timing signal....
However... I have found no possibility to READ the signal state.
Gerard van Draanen -- IR.TXT -- -3-
==========
As an alternate timing source, we can use the PC's baudrate-generator
in the PC RS232 poort.
PC adress 0:400-401 ==> COM 1 adress (Normally $3F8) ==> UART-BASE
0:402-403 ==> COM 2 adress
UART-BASE +0 = TX/RX byte buffer
en
0 = BAUD_MSByte... Before adressing this... first
1 = BAUD_LSByte UART-BASE+3 -> MSbit=1 Devid.0==> 115k2 baud
en (So ca. 10k CPS)
7654 3 2 1 0
1 = INTR-Enable 232 Stat TX TX
Empty Ready
(With this, an INT routing can be calle at each Byte TX/RX )
76543 21 0
2 = INT-ID xxxxx 00 = 232 Input INT-pending
01 = TX
10 = RX
11 = Serialization error
(Crafting C Tools... pag 379 for INT => Char->Buffer )
3 = DATA-FORMAT 7 6 5 4 3 2 1 0
Baud Set Stick Even Parity Stop Word
Latch Break Parity (0=Odd) Enable bits Length 5-8
765 4 3 2 1 0
4 = CONTROL Loop !IRQ User RTS DTR
Test
7 6 5 4 3 2 1 0
5 = SIO-STAT x XMIT XMIT RX'd Frame Par. Over Data
SHreg Hold a Error Error Run Ready
Empty Empty BREAK
(Ready to send when SIO-STAT = "0010 0000" )
7 6 5 4 3 2 1 0
6 = STAT-232 DCD RI DSR CTS DELTA DELTA DELTA DELTA
DCD RI DSR CTS
(Reading STAT-232 resets the DELTA.. [latch sig. change] )
Now, by using SIO-STAT while sending and receiving , a fixed time-base for the
bitstream sample can be achieved.
Per dataBIT on the TX line, a corresponding BIT on the CONTROL line (CTS) can
be sent. So the BIT rate on the Serial connector is needed.
_____|~|XXXXXXXXp|~|__|~|xxxxxxxxp|~|____
Data Stop Data Stop
Start Par Start Par
____ = Time available for setup of next byte
When a fixed 01010101010101 pattern can be achieved, than, that signal can be
fed-back to one of the pins, and the next BIT on the IR-led can be set up.
Sending "01010101" with EVEN parity (results in 0) & 1 stop-bit will give..
10101010101_10101010101_10101010101_ on the TX line.... SO
(1) (1) (1)on the XMIT Hold empty reg
XMIT Hold empty can function as a trigger for the (same) next Byte for the
TX line.... On each -1-0-1- transition of the TX line, a corresponding
bit from the bitstream can be handled.
Gerard van Draanen -- IR.TXT -- -4-
In principle, storing the sample Bitstream data can be done with simple
Assembler SHL, RLC, STC, CLC, SAL & JC [decr_ptr] assignments..
By first shifting a '1', then... when this first bit rolls out into the 'Carry'
bit, this can function as a trigger to decrement the byte-pointer..
So... not much overhead is needed to store the binary data
[ ] [ ]1[10011001] [10000111]
0 <==== First set of 8 samples
Determ. Fill ^ Second set of 8 samples
Max.len dire- ^ Carry bit ==> Decrement byte-pointer
Sample ction Current position byte-pointer
The very first bit in a sample is always a '1', and its presece activates the
further sampling.
At 100kHz we have ca 10 microseconds for data handling...so... not much.
After a sample has been taken, the first valid (#'0') postion will determine
the length of the sample to be stored.
Possible H/W electronic..
Z?SState-relais .. or manual
=-----3CD RTS Datacomm. RTS v: TX-> IR-led
IR-Led @Y DTR->IR-Rcv->RX <==Rcv op RX
=|<--o\ o DTR (equal to 3-wire)
\o TX
IR-Rcv Bitstream RTS ^: TX-> RI (Timing)
+->|-o\ o CTS DTR-> IR-led
| \o RX RTS->IR-Rcv->CTS <==Rcv op CTS
|
+----o\ o RTS Note: The IR receiver needs a bit of electronics to
\o DTR amplify/digitize the incoming signal.
Timing
+-ZDDD?-- TX RI+ SIO_STAT( Xmit-empty) gives timing for Send/Recv
| @DDDY by setting up a fixed 10101010 pattern on TX at 115k2
+->|----- RI
Because the RI (ring indicator) is seldomly used, this part of the h/w can
be put INSIDE of the PC. This allows the detection of a timing signal
without external hardware. When the IR-led is in parallel to the speaker,
than that can be used for Sending information.
With all this background information... I've set up an assembly language
test program, and tried that in debug. (my irgt.com uuencoded-included).
I connected the TX line to the RI line, and alternated the CTS with that
connection.
It seems to work quite nicely, I get anticipated results till 57k6, so I
guess by assembly routines could still be a bit quicker or the way I had
set up for testing was not optimal for the full 115k2 sampling rate.
So... I'm possibly in need for someone to optimize the following ir.asm
assembly programming... I may have been quite 'clumsy' with my selection of
instructions. This is due to lack of experience in the assy-programming field.
;Gerard van Draanen -- IR.TXT -- -5-
;Logical setup / flow:
$3F8 = SIO_BASE
SIO_TX_RX =0
SIO_BD_MSB=0
SIO_BD_LSB=1
SIO_DA_FMT=3
SIO_CTRL =4
SIO_STAT =5
SIO_STAT_I=6
RX_MASK =1
TX_MASK =$20
RI_MASK =$40
CTS_MASK =$10
;CLEAR A 16k+$FF BUFFER AT _OFFSET
;Debug instruction: FDS:2000L5000 00
;Variables at fixed (offset) adress $2000 [SI]
_OFFSET :
MOV SI,_OFFSET
DW 0000 ; SAFETY=0 at SI+0 and SI+1
DB 00 ; OLDRI=0 at SI+2
DB 00 ; 1ST1=0 at SI+3
DW 0000 ; SAMPSIZE=0 at SI+4 and SI+5
MOV BX,4FFF ; Max buffer length (at SI + $FF )
MOV CX,0 ; Timeout for 1st '1' sample (Loop to RD_RI )
;====
;Setup 115k2 rate , 1 stopbit, 7 databits, Even parity for 10101010101 stream
;====
;Read status, set Bit7, load Baudrate, clr Bit7
mov dx,3fb
in al,dx
;
; Check if you like
; Latch bit on
mov al,9a
out dx,al
mov dx,3f8
; LSB Baud
; xx update for testing 60=1200bd, 0c=9600bd, 06=19k2 01=115k2
mov al,01
out dx,al
inc dx
; MSB Baud
mov al,00
out dx,al
mov dx,03fb
in al,dx
; Latch bit off
and al,7f
out dx,al
;====
RTS_nDTR = 0A ; No interrupts, RTS^ DTRv
;====
SET_SIO:MOV DX,SIOBASE+SIO_CTRL
MOV AL,RTS_nDTR
OUT DX,AL
;
;Gerard van Draanen -- IR.TXT -- -6-
;
TX_RDY: MOV DX,SIOBASE+SIO_STAT ; Test --ready for xmit
IN AL,DX
AND AL,TX_MASK
CMP AL,TX_MASK
JNZ RD_RI
TX_55: MOV AL,$55 ; Xmit $55, creating 101010.. stream
MOV DX,SIOBASE+SIO_TX_RX
OUT DX,AL
RI_0: MOV AL,0
MOV [SI+2],AL ; 1st RI state will be '0' wait for '1'
PUSH AX
SAFETY: POP AX
MOV AL,1
SUB [SI+0],AL ; but don't wait forever
JNZ RD_RI
MOV AL,1
SUB [SI+1],AL
JZ EXIT_RI
RD_RI: MOV DX,SIOBASE+SIO_STAT_I
IN AL,DX
PUSH AX
AND AL,RI_MASK
CMP [SI+2],AL ; Compare to OLD RI state
JE SAFETY
MOV AL,0
MOV [SI+0],AL ; Restore safety
MOV [SI+1],AL
RD_CTS: POP AX ; Get it again
PUSH AX
AND AL,RI_MASK
MOV [SI+2],AL ; Save Current RI state
POP AX
TST_CTS:AND AL,CTS_MASK ; Test CTS
CMP AL,CTS_MASK
JZ STORE_1 ; 1
MOV AL,0 ; Test if any '1' already seen
CMP [SI+3],AL
JNZ STORE_0 ; 0
LOOP RD_RI
JMP EXIT_TIMEOUT ; Still no '1' seen after $FFFF samples
STORE_1:MOV AL,1
MOV [SI+3],AL
STC ; 'Carry'
STORE_0:MOV AL,[SI+100+BX] ; Get buffer contents
RCL AL,1 ; Roll into Buffer at [BX]
PUSHF
MOV [SI+100+BX],AL
POPF
JNC TX_RDY ; High bit rolled out ? (1st '1' sample)
MOV AL,1
ADD [SI+4],AL ; Another Byte-full of samples taken
JNZ NEXTB
ADD [SI+5],AL
NEXTB: DEC BX ; Update pointer to current sample
JNZ STORE_1
S_DONE: NOP ; Sample completed
NOP
; Normal completion ... Sample in $2000+100 -- +100+4FFF
EXIT_RI: ; Had to wait too long for RI to change state => No Freq. avail
EXIT_TIMEOUT: ; Had RI, but still no '1' sample after $FFFF tries => Empty
---- I typed this in as assembly into a debug session, and tested that.. with
'proper' results on the sample till some 50k sample rate....
So it needs a bit of optimization to be able to do 115k2 bit sampling..
---- Here's the uuencoded irgt.com ---
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
[Filename: irgt.com, Content-Type: UUEncoded]
***********************
Due to the outbreak of new viruses there is a temporary measure to block some attachment files. If you have questions please contact your local helpdesk or postmaster@xxxxxxxxxxxx
Philips Corporate IT
***********************
------
Hoping to get some respons on this.....
Thanks in advance,
Gerard.
L.G.C.M. Arendsen (Leo)
E-mail: Leo.G.Arendsen@xxxxxxxxxxx
utcke@xxxxxxxxxxxxxxx
freiburg.de To: Sharp PC 3000/3100 mailing list <sharp-pc3k@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
cc: (bcc: Leo.G. Arendsen/EHV/CIP/PHILIPS)
03/18/02 10:31 PM Subject: Internet on the Go: the PC3K and a mobile phone...
Classification:
Ok, maybe the subject is overdoing it a bit :-)
On
http://www.informatik.uni-freiburg.de/~utcke/Laptop/sharp-pc3100.html#mobile
you can find a description of my first tottering steps with the PC3K
and a Siemens S25 mobile phone.
I would be interested to hear from others with similar experiences.
In particular I'm interested to know what software you are using. Is
there an SSH version for the PC3K? I don't thin anybody build an
IrDA-option for the PC3K?
By for now...
Sven
--
IBM Thinkpad 701C, 80486 DX4/75, 40MB RAM, 3.2GB HDD, Linux 2.0.36