February 2024 - pacsat-dev - mailman.amsat.org

Re: Small bugs to fix (I think)
by Bob Stricklin 04 Feb '24

04 Feb '24

On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I've found a few minor design issues which I don't think will affect us in the short run, but may not be what we want: 1) I already told you (Bob) about the addresses for the Max temp sensors. As set, they collide with two of the possible 4 addresses on an ADS7828, a commonly-used and space-tested A/D converter that some satellite might use. We talked about this before and it should all be straightened out. Yes, Let me add this to the schematic with the new address values to be used on next board build if any. 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the MAX4995SAL power switch/limiter. While you could use these AD1IN pins as an input GPIO (read the voltage and subject it to a threshold for high or low), I don't think it is possible to use these for output. AD1EVT might be usable for output but I'm not sure what effect it would have on the bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. They appear to be usable as GPIO pins and are physically near the ADC pins. Will have to move these lines over as you indicated. Will do that with jumpers. I think the current way it is will work for the moment, since if I read the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. That is, a low value on it turns the power on, and you have a pulldown there. So I think the 5043 and the SSPA will always be on since the ADC inputs should be high impedance. 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic can't be a circuit, right? OTherwise you'd have lots of weird stuff connected together. If they are actually test points, I think they should be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. This is no problem, an artifact of KiCAD and needed to just to indicate this is a power connection so DRC handles it properly. 4) And finally, from what I have read (and seen on other projects), I don't think the SPI busses need pullup resistors EXCEPT for MISO, and that one should be VERY weak. (One of our devices does not use MISO very often but it appears not to be able to pull much current, thus requiring the really weak pullup. But as I recall a builtin pullup either was not enough, or it could not be used when the pin was used as an SPI device). I can put a scope on the MISO line for the AX5043 to see if it is getting pulled down enough with the 10K. Likewise, I'll see what the other pins look like when connected to the push/pull output of the SPI master. We will add a a pull up resistor for next build. Try to use internal pull up now and if this want cut it we can add a pull-up to these boards. Don't take these critiques as anything other than helpful. I'm no expert here...I just found these things in the process of trying to debug the software, and in a couple cases from tracking down some really PITA problems on Fox and/or Golf! No problem, you are the first person that has looked at things closely and when you start solving issues you are forced to do so. We all make mistakes I have have made plenty. Thanks. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 1

Small bugs to fix (I think)
by Burns Fisher (AMSAT) 03 Feb '24

03 Feb '24

I've found a few minor design issues which I don't think will affect us in the short run, but may not be what we want: 1) I already told you (Bob) about the addresses for the Max temp sensors. As set, they collide with two of the possible 4 addresses on an ADS7828, a commonly-used and space-tested A/D converter that some satellite might use. We talked about this before and it should all be straightened out. 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the MAX4995SAL power switch/limiter. While you could use these AD1IN pins as an input GPIO (read the voltage and subject it to a threshold for high or low), I don't think it is possible to use these for output. AD1EVT might be usable for output but I'm not sure what effect it would have on the bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. They appear to be usable as GPIO pins and are physically near the ADC pins. I think the current way it is will work for the moment, since if I read the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. That is, a low value on it turns the power on, and you have a pulldown there. So I think the 5043 and the SSPA will always be on since the ADC inputs should be high impedance. 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic can't be a circuit, right? OTherwise you'd have lots of weird stuff connected together. If they are actually test points, I think they should be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. 4) And finally, from what I have read (and seen on other projects), I don't think the SPI busses need pullup resistors EXCEPT for MISO, and that one should be VERY weak. (One of our devices does not use MISO very often but it appears not to be able to pull much current, thus requiring the really weak pullup. But as I recall a builtin pullup either was not enough, or it could not be used when the pin was used as an SPI device). I can put a scope on the MISO line for the AX5043 to see if it is getting pulled down enough with the 10K. Likewise, I'll see what the other pins look like when connected to the push/pull output of the SPI master. Don't take these critiques as anything other than helpful. I'm no expert here...I just found these things in the process of trying to debug the software, and in a couple cases from tracking down some really PITA problems on Fox and/or Golf! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Current state of software on Blinky
by Burns Fisher (AMSAT) 03 Feb '24

03 Feb '24

What I am about to describe is all checked in on the WB1FJ_Port_To_Blinky branch on the main pacsat software repository. That branch is off "main" which Chris suggested would make it easy to merge in his other changes. 1) Loading code from TI Code Composer Studio. Works just fine. 2) LEDs: The s/w is setup so that these work with the normal GPIOSetOn(LED1) and they seem to work fine. 3) FreeRTOS: It is working as nearly fine as I can see at this point. But writing this reminded me to check the clock (seconds uptime) and it was running fast, which means everything else like all the timeouts would also have been fast. That is fixed (HalCoGen setting) I have most of task commented out. This is partly because some of them complain every time they try to access the MRAM (see below) and partly because something eventually crashes. I suspect this is because the MRAM problem has generated too many errors, but I'm not sure. One thing at a time. 4) The console task and actual serial lines. Working just fine. 5) I2c: It seems to be ok. The two temp sensors are returning good stuff and the RTC appears to work, although I am not sure how to set it. I'll check that sometime. 6) SPI bus for DCT, i.e. the AX5043s. I have updated the s/w to run 5 of these. At this point I can't tell if they are working or not. I see my job as just ensuring that I can read and write registers and accept interrupts, so I am not doing ANYTHING like trying to receive or transmit RF. However, reading the registers returns something other than 0xFF so I am hopeful :-) 7) SPI Bus for MRAM: Bad news. No access at all. I have tried a very simple test: Reading and writing the MRAM status register. This does not require addresses or anything other than a simple command that should work in any state of the MRAM. The status register always reads as 0xFF. I can't access the pins on the MRAMs that are installed, but one is not installed. The SOMI line (Slave Out Master In) seems to have no continuity to the processor. Since this is a bus, it is common to all the MRAMs and thus if it really is open, that would explain the problem. I will keep checking other stuff (software!) too. That's it for the moment. There are other GPIOs that do stuff like turn on the transmitter PA that I have not done anything with. It is very easy to change the pins around for GPIOs or to add a newly named GPIO, and I will eventually spend the 5 or 10 minutes that that requires, but it is not too useful right now. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Flight software info is up now on PacSat gitHub documentation (references) folder
by Burns Fisher (AMSAT) 03 Feb '24

03 Feb '24

One was there already and I forgot! But the three of interest are: Multiple_CPUs (which really talks about the ccxml files in CCS) Use_of_HalCoGen and Software_Descirption 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: Hooray! Some serial output!
by Burns Fisher (AMSAT) 03 Feb '24

03 Feb '24

Probably the last note today unless something happens in the next hour. The console now seems fine. I've gotten to the point where I can type in commands and thus easily execute tests. I actually commented out starting the other tasks so I could pay attention to one thing at a time. I also commented out initializing the RTC--that was hanging for some reason. I'm getting a lot of errors, as the system starts up largely because (I think) the MRAM values are not what it expects. So I thought I would start on the MRAM. There is a simple command call "get mram sr" which reads the status registers of all 4 MRAMs and prints it out. That seemed like an easy place to start. However, all of them are returning 0xFF. Remember that an SPI master does not really have any way to tell if the slave is responding. The data lines are high by default, so 0xFF is typically what you get when the slave does not respond. I've done a lot of checking and found some stuff in HalCoGen that I did not have right, but still no good response even after I fixed those places (I'm comparing them with the HalCoGen on both the LaunchPad version and the RTIHU version). Just like with the serial line, I am getting appropriate interrupts. However, this time there are no wires that I might have gotten backwards. I'm going to have to check continuity on the traces from the MRAMs to the processor, at least as closely as I can. It turns out (intentionally??) that MRAM #4, which is U79 is not installed on my board. But that is helpful because that means that I can access all the SPI bus lines and at least the MRAM4 chip select line (but not the others). So I'll look at that later. Also voltages etc. SOMETHING is getting read from the AX5043s (or at least 2 of them) that is not 0xff, so they may be working. I have not poked around with I2c yet but it should be easy to set up a way to read the MAX31725s. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Feb 2, 2024 at 11:53 AM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Wow, very good. Well done. And well done Bob on the hardware. Great to > see it working. > > 73 > Chris > > On Fri, Feb 2, 2024, 10:33 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Ok, last one for the moment. The console is now working fine with >> interrupts at 38400 baud. >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Fri, Feb 2, 2024 at 10:25 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> To avoid suspense: The schematic perfectly matches what HALCOGEN claims >>> are the correct Rx and Tx pins. If I remove the connection to pin 92 (Rx) >>> it keeps going. So the blinky board is certainly correct. >>> >>> Of course Rx and Tx are relative to which end of the wire you are >>> looking at. That is Tx on the board connects to Rx on the terminal. That >>> seems like the most likely explanation. The usb/serial adapter is labelled >>> from the POV of the terminal. >>> >>> Anyway...speed test next. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Fri, Feb 2, 2024 at 10:14 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>> wrote: >>> >>>> I put in this code temporarily: >>>> >>>> >>>> GPIOEzInit(LED1); >>>> GPIOEzInit(LED2); >>>> GPIOEzInit(LED3); >>>> GPIOSetOn(LED1); >>>> GPIOSetOff(LED2); >>>> sciSetBaudrate(scilinREG, 110); >>>> sciSetBaudrate(sciREG, 110); >>>> while(1){ >>>> GPIOToggle(LED1); >>>> sciSend(sciREG,38,"Starting a test on the SCI register\r\n"); >>>> GPIOToggle(LED2); >>>> sciSend(scilinREG,38,"Starting a test on the LIN register\r\n"); >>>> } >>>> >>>> The GPIO routines are my normal driver routines. The sciSet and >>>> sciSend are the HALCoGen routines not using any interrupts or anything >>>> else. Note that I set the baudrate to 110 (R-e-a-l slow!) and sent 38 >>>> characters. That it, it should take about 3.8 seconds to print. And >>>> indeed the light pattern changes at a rate of approximately every 4 >>>> seconds. >>>> >>>> I have a terminal connected to PC104 pins 88 and 92 and set for 110 >>>> baud connected and at first saw nothing. Then I reversed the rx and tx >>>> pins and..... >>>> >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> Starting a test on the SCI register >>>> >>>> SO! Either I have the colors wrong on my serial-to-USB connector, or >>>> they are backwards on the blinky board. Will figure out which next, and >>>> then try higher speeds. >>>> >>>> >>>> 73, >>>> >>>> Burns Fisher, WB1FJ >>>> *AMSAT(R) Engineering -- Flight Software* >>>> >>> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Quick update
by Bob Stricklin 03 Feb '24

03 Feb '24

Burns, I just got back home for a day long visit to Dallas and UTD to take care of my other volunteer projects. Sounds like all good news. I am very happy to see this! Comments back from below: 1. Good on the temp sensor reading. The temp sensor you are reading is the one down next to the AX5043 transmitter chip. There is a second temp sensor at 0x91. The code will need to be changed to support this one eventually. The second temp sensor is next to the CPU chip up between memory and the CPU. You should be able to read this one also by just changing the address in the code from 0x90 to 0x91. Chris can add the second one later. We can move the I2C address to another address within the range of addresses provided on a later build. We can coordinate adding an external A/D if needed but there are several A/Ds built into the TMS570. Three of these are being used now to monitor supply voltages. The A/Ds are using 3.3V and GND for reference. The 5V A/D is AD1/N_12 and should be at 2.5V for the middle of the range. The actual 5V supply may be running a little low though so don’t be surprised if lower. The 3.3V supply is on AD1N_4. Again this should read mid range on the A/D which will be 3.3 / 2 or 1.65 volts. The 1.2 V supply is on AD1N_13 and should read 1.2 / 3.3 * (2^12). This is something you can work on testing but should work as designed. There is an option later to use two of the A/Ds on a critical measurement and then use the redundant capabilities of this CPU to make sure the readings are accurate. We could also monitor other things with more A/Ds but this should be enough for a prototype. The AX5043 readings we might measure with analog readings are available in registers I believe. 2. The one wire pull-up issue should be addressed by activating the Pull up on N2HET1_14. We could add another pull-up on the board later. I thought the idea was to have a security string on the PCB that could be matched with ground transmissions. Dropping chips if fine though as it will save current. Not much saved here though. 3. The SPI lines for the AX5043 are available on J801. We would have to add the memory SPI if needed. J801 is on one of the schematic pages. We can add the I2C bus to the PC104 if a pin set is defined and the signals are needed there. We will have to coordinate this with others. I could do this with a couple of jumpers if thee is an advantage to it now. We need to be careful with two Masters and adding capacitance to the line. Also voltages between systems. The box I am building will have the PC104 available from the top for accessing the serial port and other things. I was thinking of making a small PCB that just picks up a few of the pins on the end to make the serial port connection easier and from outside the box. Add a couple of indicator LEDs also. Please test the memory and see if any of it is working. This will need some work on the SPI pin selection and probably what you have already figured out. Would like to see if you can read and write anything to each of the 5 AX5043s. When we get through all of the above then all the CPU related things will have been tested. You would need jumper cables just to feed signals on and off the AX5043 for RF test so this should probably come later. Just reading and writing to the devices would be a good milestone. Bob On Feb 2, 2024, at 4:52 PM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: I2c works. Pacsat>get i2c I2c device state: (1 is ok) PacSat Board Temp: 1 RTC: 1 Pacsat>get rtc Date: 2000-1-1 06:18:45 UTC Time: 946707525 vs IHU Unix time 1000000132 Pacsat>get temp Pacsat board temp is 92 ( 26.0 degrees C) Comments for the future: 1) The temp sensors should be at different addresses. We have no ADS7828 I2c A/D converters, but they are very useful and space-proven gadgets for reading voltages, etc. However, the "easy" temp addresses clash with the 7828. It's hard to see becasue Max uses 8 bit values for addresses (with bit 0 set to 0) while the rest of the world uses 7 bit values. So Max's address 0x90 is really 0x48 to everyone else. 2) The one-wire secure memory is totally unused and I never managed to make it work on the RTIHU. I think it needs a pullup (I don't recall why the builtin pullup does not work). But regardless, I suppose we could put an encryption key in it, but it is not especially useful when it is flying in space anyway :-) 3) In the future it would be nice to have SPI and I2c busses available at test points. Or even on the PC104. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software

1 0

Re: Just a note for the Blinky board AX5043
by Chris Thompson 02 Feb '24

02 Feb '24

Yes, we found that 91nH worked on Jim's board. But the actual value will depend on board layout and any stray inductance. 73 Chris On Fri, Feb 2, 2024, 11:41 Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Correct. > > 91nH or something close. It sets the PLL bandwidth. > > > > Congrats by the way. > > > > Jim > > > > This won't stop me for anything I will do, but the receiver will not lock > (VHF) unless the iplace marked "jumper if no inductor" actually has an > inductor. I think short is ok for UHF but VHF needs 91nH. (Do you > remember, Jim?) > > > 73, > > > > Burns Fisher, WB1FJ > > *AMSAT**(R) **Engineering -- Flight Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Hooray! Some serial output!
by Chris Thompson 02 Feb '24

02 Feb '24

Wow, very good. Well done. And well done Bob on the hardware. Great to see it working. 73 Chris On Fri, Feb 2, 2024, 10:33 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Ok, last one for the moment. The console is now working fine with > interrupts at 38400 baud. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, Feb 2, 2024 at 10:25 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> To avoid suspense: The schematic perfectly matches what HALCOGEN claims >> are the correct Rx and Tx pins. If I remove the connection to pin 92 (Rx) >> it keeps going. So the blinky board is certainly correct. >> >> Of course Rx and Tx are relative to which end of the wire you are looking >> at. That is Tx on the board connects to Rx on the terminal. That seems >> like the most likely explanation. The usb/serial adapter is labelled from >> the POV of the terminal. >> >> Anyway...speed test next. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Fri, Feb 2, 2024 at 10:14 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> I put in this code temporarily: >>> >>> >>> GPIOEzInit(LED1); >>> GPIOEzInit(LED2); >>> GPIOEzInit(LED3); >>> GPIOSetOn(LED1); >>> GPIOSetOff(LED2); >>> sciSetBaudrate(scilinREG, 110); >>> sciSetBaudrate(sciREG, 110); >>> while(1){ >>> GPIOToggle(LED1); >>> sciSend(sciREG,38,"Starting a test on the SCI register\r\n"); >>> GPIOToggle(LED2); >>> sciSend(scilinREG,38,"Starting a test on the LIN register\r\n"); >>> } >>> >>> The GPIO routines are my normal driver routines. The sciSet and sciSend >>> are the HALCoGen routines not using any interrupts or anything else. Note >>> that I set the baudrate to 110 (R-e-a-l slow!) and sent 38 characters. >>> That it, it should take about 3.8 seconds to print. And indeed the light >>> pattern changes at a rate of approximately every 4 seconds. >>> >>> I have a terminal connected to PC104 pins 88 and 92 and set for 110 >>> baud connected and at first saw nothing. Then I reversed the rx and tx >>> pins and..... >>> >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> Starting a test on the SCI register >>> >>> SO! Either I have the colors wrong on my serial-to-USB connector, or >>> they are backwards on the blinky board. Will figure out which next, and >>> then try higher speeds. >>> >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >> > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Just a note for the Blinky board AX5043
by Jim McCullers 02 Feb '24

02 Feb '24

Correct. 91nH or something close. It sets the PLL bandwidth. Congrats by the way. Jim This won't stop me for anything I will do, but the receiver will not lock (VHF) unless the iplace marked "jumper if no inductor" actually has an inductor. I think short is ok for UHF but VHF needs 91nH. (Do you remember, Jim?) 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software

1 0

Just a note for the Blinky board AX5043
by Burns Fisher (AMSAT) 02 Feb '24

02 Feb '24

This won't stop me for anything I will do, but the receiver will not lock (VHF) unless the iplace marked "jumper if no inductor" actually has an inductor. I think short is ok for UHF but VHF needs 91nH. (Do you remember, Jim?) 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Hooray! Some serial output!
by Burns Fisher (AMSAT) 02 Feb '24

02 Feb '24

I put in this code temporarily: GPIOEzInit(LED1); GPIOEzInit(LED2); GPIOEzInit(LED3); GPIOSetOn(LED1); GPIOSetOff(LED2); sciSetBaudrate(scilinREG, 110); sciSetBaudrate(sciREG, 110); while(1){ GPIOToggle(LED1); sciSend(sciREG,38,"Starting a test on the SCI register\r\n"); GPIOToggle(LED2); sciSend(scilinREG,38,"Starting a test on the LIN register\r\n"); } The GPIO routines are my normal driver routines. The sciSet and sciSend are the HALCoGen routines not using any interrupts or anything else. Note that I set the baudrate to 110 (R-e-a-l slow!) and sent 38 characters. That it, it should take about 3.8 seconds to print. And indeed the light pattern changes at a rate of approximately every 4 seconds. I have a terminal connected to PC104 pins 88 and 92 and set for 110 baud connected and at first saw nothing. Then I reversed the rx and tx pins and..... Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register Starting a test on the SCI register SO! Either I have the colors wrong on my serial-to-USB connector, or they are backwards on the blinky board. Will figure out which next, and then try higher speeds. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 2

Re: Pacsat dev mtg 2/1/2024
by Bob Stricklin 02 Feb '24

02 Feb '24

Here are some photos which show the RX1 TX1 pins used on the PCB. Also the same pins used on the Launchpad board shown on the connect shots below, On the TI drawing it is J2 pins 3 (RX) and 4 (TX). On Jims schematic it is J2 pins 5 (RX) and 7 (TX). So the three pins needed are together on the PC104, Pin 92 (RX), Pin 88 (TX), and GND (Pin 84). You can see from the hilite on the PCB the lines go directly from the CPU to the pins. The maximum voltage on these pins is +4.6V. Be careful with this. Bob [cid:[email protected]][cid:[email protected]][cid:[email protected]] [cid:[email protected]][cid:[email protected]] On Feb 1, 2024, at 4:53 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: FYI, I have another meeting at 7 which may not be done in time. I'll come if I can. But for my report: I have the software loading as a git branch from what Chris is using, and it starts up fine, including starting the OS. At some point it resets, but I'm not worried about that yet. Right now I am trying to get anything out of the serial port with no luck even just jamming a character directly into UART transmit buffer. So I'm starting to think this is a hardware issue. Either on the board, or more likely that I have the rx/tx lines reversed, or plugged into the wrong two pins (out of 104!) 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 1, 2024 at 5:13 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Pacsat dev mtg 2/1/2024 Thu, Feb 1, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/133573605 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (646) 749-3122 - One-touch: tel:+16467493122,,133573605# Access Code: 133-573-605 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com<http://inroomlink.goto.com/> Meeting ID: 133 573 605 Or dial directly: 133573605(a)67.217.95.2<mailto:[email protected]> or 67.217.95.2##133573605 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Pacsat dev mtg 2/1/2024
by Burns Fisher (AMSAT) 01 Feb '24

01 Feb '24

FYI, I have another meeting at 7 which may not be done in time. I'll come if I can. But for my report: I have the software loading as a git branch from what Chris is using, and it starts up fine, including starting the OS. At some point it resets, but I'm not worried about that yet. Right now I am trying to get anything out of the serial port with no luck even just jamming a character directly into UART transmit buffer. So I'm starting to think this is a hardware issue. Either on the board, or more likely that I have the rx/tx lines reversed, or plugged into the wrong two pins (out of 104!) 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 1, 2024 at 5:13 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > Pacsat dev mtg 2/1/2024 > Thu, Feb 1, 2024 7:00 PM - 9:00 PM (CST) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/133573605 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (646) 749-3122 > - One-touch: tel:+16467493122,,133573605# > > Access Code: 133-573-605 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 133 573 605 > Or dial directly: 133573605(a)67.217.95.2 or 67.217.95.2##133573605 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Pacsat dev mtg 2/1/2024
by Bill 01 Feb '24

01 Feb '24

Pacsat dev mtg 2/1/2024 Thu, Feb 1, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/133573605 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (646) 749-3122 - One-touch: tel:+16467493122,,133573605# Access Code: 133-573-605 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 133 573 605 Or dial directly: 133573605(a)67.217.95.2 or 67.217.95.2##133573605 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Schematic of Blinky
by Burns Fisher (AMSAT) 01 Feb '24

01 Feb '24

That works fine with the default pdf reader on a Mac. I'm sure as long as the text is in there (rather than an image) any PDF reader with search capability will be ok. Thanks! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 1, 2024 at 6:41 AM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > Here is a PDF which was plotted using HTML format (there are several > plotting options) and I can search the resulting file in Ubuntu have not > tried Windows. In windows you may need to have Adobe Acrobat application on > you system. > > Bob > > > On Jan 31, 2024, at 1:44 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Thanks for the spreadsheet. But I can't search in the schematic you sent > either. PRINT is not the way to go for a searchable PDF. You need to > PLOT. It does not seem to make any difference other than the text. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Wed, Jan 31, 2024 at 2:25 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Burns, > > I believe the copy on GitHub was printed but here is one I just made which > for sure is printed. > Note this is Rev D and includes some changes but most of these are not > related to software. > > I am also attaching the spread sheet I did in the past and updated > recently which is a list of pin assignments from the CPU. This is easier to > work with for a software reference. > > Bob > > > > > > On Jan 31, 2024, at 12:18 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Actually, I just found them on the PC104. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Wed, Jan 31, 2024 at 1:13 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > > Hi Bob, > > I'm just getting started on software for the Blinky, but to do that, I > need to find things on the schematic. I found the schematic on gihub > (Schematic_231004.pdf) but it is not searchable, so I really can't find > (easily) where traces connect. For example, I found "UART_TX1 (as well as > RX1,2 and Tx2) but can't easily see what they connect to. Is there a > header somewhere (I could not see that on the physical board). > > If you can tell me where the UART lines go reasonbly soon, that would > help, but in the slightly longer term if you can make a KiCad PDF schematic > with the "plot" command rather than the "print" command (the ONLY thing > that I know about Kicad, I might add), that will produce a PDF with actual > text in it such that it can be searched. > > Thanks! > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Schematic of Blinky
by Bob Stricklin 01 Feb '24

01 Feb '24

Burns, Here is a PDF which was plotted using HTML format (there are several plotting options) and I can search the resulting file in Ubuntu have not tried Windows. In windows you may need to have Adobe Acrobat application on you system. Bob On Jan 31, 2024, at 1:44 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Thanks for the spreadsheet. But I can't search in the schematic you sent either. PRINT is not the way to go for a searchable PDF. You need to PLOT. It does not seem to make any difference other than the text. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Jan 31, 2024 at 2:25 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Burns, I believe the copy on GitHub was printed but here is one I just made which for sure is printed. Note this is Rev D and includes some changes but most of these are not related to software. I am also attaching the spread sheet I did in the past and updated recently which is a list of pin assignments from the CPU. This is easier to work with for a software reference. Bob On Jan 31, 2024, at 12:18 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Actually, I just found them on the PC104. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Jan 31, 2024 at 1:13 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Hi Bob, I'm just getting started on software for the Blinky, but to do that, I need to find things on the schematic. I found the schematic on gihub (Schematic_231004.pdf) but it is not searchable, so I really can't find (easily) where traces connect. For example, I found "UART_TX1 (as well as RX1,2 and Tx2) but can't easily see what they connect to. Is there a header somewhere (I could not see that on the physical board). If you can tell me where the UART lines go reasonbly soon, that would help, but in the slightly longer term if you can make a KiCad PDF schematic with the "plot" command rather than the "print" command (the ONLY thing that I know about Kicad, I might add), that will produce a PDF with actual text in it such that it can be searched. Thanks! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0