Posts by ChristophB

    Hi everyone,


    I hope the UART-forum is the right one for my request. If not, please move it to the correct place.


    According to the documentation (Telit_AT_Commands_Reference_Guide_r17.pdf), the module checks the DTR port-level if start mode 0 is selected. In our circuit-board, there is a 2.8V-LDO as VCCIO for an FTDI-USB-UART-Chip. The communication with the GC864-QUAD-V2 works fine. The 2.8V-LDO is only activated when a USB-cable is plugged in (USB 5V are the power supply for the chip). This is supposed to be used as a check whether or not the script shall be executed (if a USB-cable is plugged in, the terminal mode for programming is needed and thus, the script must not be executed). Conected to the DTR is also a pull-down resistor so in normal operating mode, the script is started.


    The problem is, that no matter what the level on the DTR-pin, the script always starts. I have also used Pythons SER.getDTR()-function, but either way, with USB cable connected and disconnected, the return value is always 0.


    All relevant connections are shown in the following image:


    [Blocked Image: http://i.imgur.com/G7AVq1a.png]


    If there is anything left unclear, feel free to ask and I will answer. Hopefully, someone can help me with this issue.


    Regards,


    ChristophB

    The problem has been solved. For everyone interested:


    The duration of bootloader upload has been decreased by using AT#CPUMODE=3. We need not worry about Power Saving, so this is ok.


    Regards,


    ChristophB

    Hi!


    Module: GC864-QUAD
    Firmware: 10.00.065


    My goal is to program a uController, that sits at the other end of the serial line, with a downloaded Firmware. For this I first need to upload a Bootloader (~40kB) to the uController. Due to the size, the bootloader has to be saved as a file in the memory of the module. Now I have tried serveral approaches including reading the bootloader-file 2000-bytewise and converting it byte by byte from a string to a byte so I can use the function SER.sendbyte(). Unfortunately this method is incredibly slow. SER.send() seems much faster and better suited for my needs. The only problem is, that I need to send the correct values. For example: If the uC expects a byte 0x56, I might also send a string 'V'.
    The bootloader file is a simple text file with hexadecimal values inside; e.g. it begins with '9FA083EF871F9B07'. Is there a possibility with this Python version to read these values in a way I can send them with the much faster SER.send()? Note that there are non-standard ascii characters possible (9F), so converting it on PC beforehand into ASCII is not an option.
    I thought of something along the lines of adding a '\x' in the string, so it would be recognized as hex. This does not work, however.


    Any help would be greatly appreciated!


    Regards,


    ChristophB

    Hi!


    I still have trouble with the routine. To clear things up a bit:


    When I am using AT#FTPRECV=3000 (e.g.) in the console, I receive the output in the console, i.e. the SerialPort. To get this very same output inside the program, I need to use the MDM functions, right? Does the flow control change the behaviour of the MDM/MDM2-port? Or is it only for the SER-port?


    The routine you posted is, as I see it, only for reading out one answer to AT#FTPRECV=3000, am I right about that? The problem is, when trying your solution, I ended up not even getting in the routine, because my MDM2.getDCD() was always zero.


    Why exactly did you use MDM2? Do I need to send the command to the MDM2-port then aswell or does it not matter?


    I am sorry for all these questions, but I just can't seem to get it working.


    Regards and thank you very much for your patience with me!


    ChristophB

    Hi!


    I am checking the answer, see, I am writing it to a file and afterwards (when the script is finished), I download the file from the module to read from it. Sometimes, I did not write it down but sent it over the SER port to immediatly check the answer. It was always the same, sometimes #FTPRECV=900something, sometimes 400something and sometimes 0.


    The part that I do not understand is, that in the command-line from RSTerm or HTerm, it is working just fine and I always get #FTPRECV=2000. Can it have something to do with FlowControl? In HTerm, CTS FlowControl is of course checked, but when I use MDM.read to get what the module would be sending to the serial port otherwise, I have no control abour that.


    Any ideas?


    Thanks in advance!


    Regards,


    ChristophB

    Good morning!


    Sorry, I didn't clarify this, yes I am indeed using Python for programming. To get ahead of further questions, the code is:



    The , behind serv and usr are needed in the syntax of FTPOPEN, I integrated them in the string directly. WriteToDisk is working just fine.


    Regards, ChristophB

    Hi!


    I am currently trying to use my TER-GX300S to download a big file via FTP. (>16kB, therefore not possible to just store it into one variable with FTPGET). My approach (with a public server) is:


    AT#GPRS=1
    AT#FTPOPEN=ftp.rz.uni-wuerzburg.de,ftp,test@web.de
    AT#FTPCWD=pub/amiga/aminet
    AT#FTPGETPKT=README
    loop until I find "ERROR":
    char = AT#FTPRECV=3000
    WriteToFile(char, append)


    WriteToFile is a selfmade function using file I/O, which is working just fine, the rest is sent to the MDM Interface/read from the MDM Interface. When I do all these commands with e.g. HTerm, it works just fine and the module receives the file 2000-byte wise. (Though I am not quite sure, why not 3000-byte wise)


    When I run the code, however, sometimes I get #FTPRECV=486, sometimes even #FTPRECV=0 within the MDM.receive stream. Also, the last lines of the file are cutoff. Please feel free to test it out with this ftp server yourself.


    Is there any known issue that could cause such behaviour; Is there any timeout I need? (between the commands, I always use MOD.sleep(10) (atleast)


    AT+GMM: GC864-QUAD
    AT+GMR: 10.00.065


    Regards,


    ChristophB

    Guten Morgen!


    Auf diese Art und Weise kann ich keine Strings einlesen, bzw. wird das eine Zeichen, nachdem das Script sich beendet, nicht zurückgegeben. Warum noch einmal die str()-Konvertierung? SER.receive sollte doch bereits einen String als Rückgabewert haben.
    Die Methode, die ich gestern gefunden habe:


    import SER
    SER.set_speed('115200')
    SER.send('TYPE NOW\n\r')
    res = ''
    while(1):
    res=res+SER.receive(20)
    if((res[len(res)-1:])=='\r'): # Wenn letzte beide Zeichen ein CR sind, wird ausgegeben und abgebrochen.
    SER.send('Text:\n\r')
    SER.send(res + '\r\n')
    break


    Das einzige Problem daran ist, dass man nicht sieht, was man tippt (zumindest im RSTerm nicht, werde das ganze nochmal mit einem anderen Terminal Programm versuchen).


    MfG


    ChristophB

    Hallo,


    Ich versuch gerade, an meinen Python-Interpreter im TER-GX300S Daten über den Serial-Port zu senden und komme weder mit SER.receive noch SER.receivebyte auf einen grünen Zweig. Vom Interpreter an den Computer funktionert hingegen ohne Probleme.


    Mein Testprogramm:


    import SER
    SER.set_speed('115200')
    SER.send('Starting...')
    b = SER.receive(30)
    SER.send(b)


    Ebensowenig funktioniert es mit SER.read.


    Mache ich etwas offensichtliches falsch?


    LG


    ChristophB

    Hallo,


    Ich habe den Tag heute damit verbracht, o.g. Software korrekt zum Laufen zu bringen und da ich damit leider keinen Erfolg hatte, melde ich mich hier im Forum. Ich habe diese Version runtergeladen, da ich auf einer 64-BIT Windows 7 Plattform arbeite und über die 4 virtuellen Ports u.a. meinen Python-Debug-Stream ansehen möchte.


    Die Software installiert sich zwar korrekt, aber sobald ich sie starte (alle virtuellen Ports auf 'Idle') und mit einem Serial-Monitor den Datenverkehr einer der Ports mitschneiden möchte, steht in der Software 'Error'. Das passiert mit jedem der Ports, in jeder Reihenfolge.


    Woran kann das liegen?


    Vielen Dank im Voraus und mit freundlichen Grüßen,


    Christoph Bismark


    UPDATE: jetzt funktioniert das ganze, ohne dass ich was geändert habe.. zumindest nicht aktiv bewusst. Gibt es da schon Erfahrungen mit, was diesen vorherigen Fehler auslösen könnte?