summaryrefslogtreecommitdiff
authorJamey Sharp <jamey@minilop.net>2007-11-15 04:56:09 (GMT)
committer Jamey Sharp <jamey@minilop.net>2007-11-15 04:56:54 (GMT)
commita44828863dff1fdc171b8772ba65d0ffd2f6ff31 (patch) (side-by-side diff)
tree48fbd7a856f7cbf1e9627aee8680dc41f1144c74
parent0df1af9a9c487dbe3144ebceb6579011f960002c (diff)
downloadwiki-a44828863dff1fdc171b8772ba65d0ffd2f6ff31.zip
wiki-a44828863dff1fdc171b8772ba65d0ffd2f6ff31.tar.gz
Unlink acronyms that were mistakenly made into links during conversion.
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--AandTBatteriesLv2.mdwn4
-rw-r--r--AtvCameraForLv2.mdwn2
-rw-r--r--AtvCanNodeForLv2.mdwn8
-rw-r--r--AtvDistroBoard.mdwn2
-rw-r--r--AvionicsLv2.mdwn8
-rw-r--r--AvionicsPartsLv2.mdwn2
-rw-r--r--AvionicsPayloadInfoLv2.mdwn4
-rw-r--r--AvionicsPowerSystemLv2.mdwn2
-rw-r--r--AvionicsPowerSystemLv2Calibration.mdwn2
-rw-r--r--AvionicsTeamHome.mdwn4
-rw-r--r--BatteryPackLv2.mdwn10
-rw-r--r--BatteryResearchLv2.mdwn2
-rw-r--r--BlockDiagram.mdwn2
-rw-r--r--CanBusUtilization.mdwn4
-rw-r--r--CanNodeFirmwareGps.mdwn2
-rw-r--r--CanNodeFirmwareImu.mdwn4
-rw-r--r--CanNodeSectionAppPower.mdwn2
-rw-r--r--CanNodeSectionProcessor.mdwn2
-rw-r--r--CanNodes.mdwn6
-rw-r--r--CantalopeHardware.mdwn2
-rw-r--r--CurrentBringList.mdwn8
-rw-r--r--GroundSupport.mdwn6
-rw-r--r--HybridBudget.mdwn4
-rw-r--r--HybridSequencer.mdwn2
-rw-r--r--LinkBudget.mdwn4
-rw-r--r--ListOfPCMCIABoards.mdwn2
-rw-r--r--LoadCellAmp.mdwn2
-rw-r--r--Lv2LaunchTowerElectronics.mdwn4
-rw-r--r--Lv2LaunchTowerRelay.mdwn2
-rw-r--r--LvTwoAmateurTelevisionOverview.mdwn2
-rw-r--r--PicCore.mdwn2
-rw-r--r--PicCore/blog.mdwn4
-rw-r--r--PicCore/docs.mdwn2
-rw-r--r--PicCore/docs/errors.mdwn2
-rw-r--r--PsasCantalopePage.mdwn2
-rw-r--r--PsasRoadMap.mdwn2
-rw-r--r--RecoveryNodeLV2.mdwn2
-rw-r--r--SjaCanTestNode.mdwn4
-rw-r--r--SmartBatteriesLv2.mdwn2
-rw-r--r--Sponsors.mdwn2
-rw-r--r--TheoryOfOperation.mdwn4
-rw-r--r--UplinkLv1.mdwn4
-rw-r--r--news/1999-04-11/data.mdwn2
-rw-r--r--news/2000-10-07/data.mdwn4
-rw-r--r--news/2001-08-02.mdwn2
-rw-r--r--news/2001-08-15.mdwn4
-rw-r--r--news/2002-02-06.mdwn2
-rw-r--r--news/2002-02-27.mdwn2
-rw-r--r--news/2002-04-07.mdwn2
-rw-r--r--news/2002-04-14.mdwn6
-rw-r--r--news/2002-04-28.mdwn4
-rw-r--r--news/2002-05-14.mdwn2
-rw-r--r--news/2002-05-26.mdwn2
-rw-r--r--news/2002-06-18.mdwn2
-rw-r--r--news/2002-06-25.mdwn4
-rw-r--r--news/2002-07-07.mdwn2
-rw-r--r--news/2002-09-22/logistics/people.mdwn16
-rw-r--r--news/2003-10-06.mdwn2
-rw-r--r--news/2003-10-13.mdwn2
-rw-r--r--news/2004-02-12.mdwn2
-rw-r--r--news/2004-05-02.mdwn2
-rw-r--r--news/2004-06-27.mdwn2
-rw-r--r--news/2004-10-27.mdwn2
-rw-r--r--news/2004-12-07.mdwn2
-rw-r--r--news/2004-12-22.mdwn2
-rw-r--r--news/2005-03-22.mdwn2
-rw-r--r--news/2005-07-03.mdwn2
-rw-r--r--news/2005-10-06.mdwn2
68 files changed, 110 insertions, 110 deletions
diff --git a/AandTBatteriesLv2.mdwn b/AandTBatteriesLv2.mdwn
index 693c516..9e9fd50 100644
--- a/AandTBatteriesLv2.mdwn
+++ b/AandTBatteriesLv2.mdwn
@@ -1,4 +1,4 @@
-# <a name="AT Batteries _LGQ863448H"></a> A&amp;T Batteries [[LGQ863448H]]
+# <a name="AT Batteries _LGQ863448H"></a> A&amp;T Batteries LGQ863448H
<table border=1 cellpadding=0 cellspacing=0>
<tr>
@@ -22,7 +22,7 @@ We're not sure what the "H" designation means. Hopefully something like the term
</tr>
<tr>
<td> Model: </td>
- <td>[[LGQ863448H]]</td>
+ <td>LGQ863448H</td>
</tr>
<tr>
<td> Distributer: </td>
diff --git a/AtvCameraForLv2.mdwn b/AtvCameraForLv2.mdwn
index 6a13bd5..eca2f1b 100644
--- a/AtvCameraForLv2.mdwn
+++ b/AtvCameraForLv2.mdwn
@@ -38,4 +38,4 @@ Here's the final product _before_ we mounted it:
Wide Angle lenses only:
- CML2.5MM $29.95
-- [[CML4MM]] $24.95
+- CML4MM $24.95
diff --git a/AtvCanNodeForLv2.mdwn b/AtvCanNodeForLv2.mdwn
index 24061d0..e89cb0e 100644
--- a/AtvCanNodeForLv2.mdwn
+++ b/AtvCanNodeForLv2.mdwn
@@ -1,6 +1,6 @@
## <a name="ATV Can Node"></a> ATV Can Node
-It's a [[PIC16F877]] + SJA1000 "MISC" PCB modified to use a [[PIC18F458]] running at 20MHz. It also has the following pin hooked up to the ATV distribution board:
+It's a PIC16F877 + SJA1000 "MISC" PCB modified to use a PIC18F458 running at 20MHz. It also has the following pin hooked up to the ATV distribution board:
<table border=1 cellpadding=0 cellspacing=0>
<tr>
@@ -31,7 +31,7 @@ It's a [[PIC16F877]] + SJA1000 "MISC" PCB modified to use a [[PIC18F458]] runnin
<tr>
<td> RD2 </td>
<td align="center"> 40 </td>
- <td> ATV transmitter [[IPS5451S]] input (ATV TX power on/off) </td>
+ <td> ATV transmitter IPS5451S input (ATV TX power on/off) </td>
</tr>
<tr>
<td> RD3 </td>
@@ -41,7 +41,7 @@ It's a [[PIC16F877]] + SJA1000 "MISC" PCB modified to use a [[PIC18F458]] runnin
<tr>
<td> RD4 </td>
<td align="center"> 02 </td>
- <td> Overlay board [[IPS511S]] input (overlay board power on/off) </td>
+ <td> Overlay board IPS511S input (overlay board power on/off) </td>
</tr>
<tr>
<td> RD5 </td>
@@ -51,7 +51,7 @@ It's a [[PIC16F877]] + SJA1000 "MISC" PCB modified to use a [[PIC18F458]] runnin
<tr>
<td> RD6 </td>
<td align="center"> 04 </td>
- <td> Camera [[IPS511S]] input (camera power on/off) </td>
+ <td> Camera IPS511S input (camera power on/off) </td>
</tr>
</table>
diff --git a/AtvDistroBoard.mdwn b/AtvDistroBoard.mdwn
index c84e123..05b59d0 100644
--- a/AtvDistroBoard.mdwn
+++ b/AtvDistroBoard.mdwn
@@ -1,6 +1,6 @@
## <a name="ATV Distribution Board for LV2"></a> ATV Distribution Board for LV2
-The distribution board connects the camera, overlay board, Misc [[PIC18F]] CAN node, and ATV transmitter and ATV power amp. It also switches each component on and off via "Intelligent Power Switches" from International Rectifier (basically, high-side MOSFETs).
+The distribution board connects the camera, overlay board, Misc PIC18F CAN node, and ATV transmitter and ATV power amp. It also switches each component on and off via "Intelligent Power Switches" from International Rectifier (basically, high-side MOSFETs).
See the PDF schematic of the version 2 board, built by Tim Ressel, is below.
diff --git a/AvionicsLv2.mdwn b/AvionicsLv2.mdwn
index d39fd68..36a0644 100644
--- a/AvionicsLv2.mdwn
+++ b/AvionicsLv2.mdwn
@@ -21,8 +21,8 @@
- [[Launch Tower Computer (LTC)|Lv2LaunchTowerComputer]]: A Linux-based x86 PC104 stack with Lucent Orinoco 802.11b card and CAN.
- [[24dBi 2.4GHz 802.11b parabolic dish antenna|CommunicationsTeamHome]] ("BBQ" grill antenna).
-- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: [[PIC18F458]]-based CAN node with four relays and some analog sampling.
-- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: [[PIC18F458]]-based board which provides rocketready relay interlock in firing chain.
+- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: PIC18F458-based CAN node with four relays and some analog sampling.
+- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: PIC18F458-based board which provides rocketready relay interlock in firing chain.
- [[Launch Igniter Circuit|Lv2LaunchTowerIgniter]]: igniter circuit for launch igniter.
- [[Umbilical cord|Lv2UmbilicalCord]]: Connects LV2 to the electronics box. Provides shore power, includes rocketready relay interlock.
- [[Launch Tower Power System|Lv2LaunchTowerPower]]:Solar array, charge controller, and battery
@@ -33,7 +33,7 @@
## <a name="Firmware"></a> Firmware
-- [[PicCore]]: An open source application framework in C for the Microchip [[PIC18Fxxx]]
+- [[PicCore]]: An open source application framework in C for the Microchip PIC18Fxxx
- [[CanFirmwareConventions]]
- LV2 CAN Node Firmware:
@@ -56,7 +56,7 @@
- [[RocketNames]]: Project wide naming conventions for systems, schematics, etc.
- [[GerberTools]]
- [[AvionicsSVNAccess]]: getting access to the Avionics software itself
-- [[SjaCanTestNode]]: [[PIC16F877]]/SJA1000 based CAN node for testing the FC/LTC
+- [[SjaCanTestNode]]: PIC16F877/SJA1000 based CAN node for testing the FC/LTC
- [[CANtalope|PsasCantalopePage]] CAN protocol monitor.
- [[EagleCad]]: Cadsoft's EAGLE schematic capture/PCB CAD program
- [[LPKF 91 router information|LpkfRouter]]
diff --git a/AvionicsPartsLv2.mdwn b/AvionicsPartsLv2.mdwn
index ae8a07f..0f3f831 100644
--- a/AvionicsPartsLv2.mdwn
+++ b/AvionicsPartsLv2.mdwn
@@ -15,7 +15,7 @@
### <a name="Holtek IC for Recovery Node"></a> Holtek IC for Recovery Node
-> [[HT9170D]]
+> HT9170D
>
> DTMF Tone decoder
diff --git a/AvionicsPayloadInfoLv2.mdwn b/AvionicsPayloadInfoLv2.mdwn
index 4193ced..249eff3 100644
--- a/AvionicsPayloadInfoLv2.mdwn
+++ b/AvionicsPayloadInfoLv2.mdwn
@@ -12,12 +12,12 @@ LV2 uses 2.422GHz, 1.57542GHz, and 1.277GHz radio systems. There are also some I
## <a name="Microcontroller"></a> Microcontroller
-Use whatever you'd like! Note that we have [[PIC18F458]] nodes available for your use.
+Use whatever you'd like! Note that we have PIC18F458 nodes available for your use.
## <a name="Telemetry"></a> Telemetry
You can use LV2's telemetry system, but unfortuantely only via a PSAS CAN node.
-The [[PIC18F458]] CAN node has a ton of available peripherals: UART, 10bit ADC, GPIO, PWM, timers, etc. And we can probably whip out simple programs for you: sampling sensors, toggling ports, etc.
+The PIC18F458 CAN node has a ton of available peripherals: UART, 10bit ADC, GPIO, PWM, timers, etc. And we can probably whip out simple programs for you: sampling sensors, toggling ports, etc.
Note that if you want to run your own microcontroller, there's a great way to get your data down with a minimum of hassle: we can create a "virtual UART" using a CAN node. Plug your uC's UART into the PSAS CAN node and we'll packetize the serial steam on the CAN bus, and log it or send it down the telemetry system for you.
diff --git a/AvionicsPowerSystemLv2.mdwn b/AvionicsPowerSystemLv2.mdwn
index 8e1e713..2bd87f8 100644
--- a/AvionicsPowerSystemLv2.mdwn
+++ b/AvionicsPowerSystemLv2.mdwn
@@ -21,7 +21,7 @@ The Avionics Power System (APS) provides power and load switching to the avionic
- An "active diode" controller to switch between the battery and shore power.
- Four power switches to switch various vehicle systems on and off, e.g. RF power amplifiers, flight computer, etc.
- A 5V SPS with a linear bypass for for low power standby
-- A [[PIC18F458]] microcontroller to control the system and interface it to the CAN bus.
+- A PIC18F458 microcontroller to control the system and interface it to the CAN bus.
The current version of the APS is v0.6, which was fabbed by PCBexpress 2004/09/08 and finished 2004/09/19.
diff --git a/AvionicsPowerSystemLv2Calibration.mdwn b/AvionicsPowerSystemLv2Calibration.mdwn
index 8206872..5d67801 100644
--- a/AvionicsPowerSystemLv2Calibration.mdwn
+++ b/AvionicsPowerSystemLv2Calibration.mdwn
@@ -2,7 +2,7 @@
## <a name="Calibrating Battery Voltage"></a> Calibrating Battery Voltage
-The [[PIC18F458]] reads the battery voltage and NOT the avionics system bus voltage, which switches between the battery and shore power. It reads an onboard 10bit ADC which is connected to the battery via a resistive voltage divider, which in turn is turned on by a [[ZXMN2A01F]] N-channel MOSFET. The divider is R1 = 115K, R2 = 20K which gives a theoretical divide by factor of 0.14815. Thus Vb should be 5/1024/0.14815\*(raw ADC). Since the resistors are only 1%, and the MOSFET adds it's own resistance, we'll simply modify the voltage divider constant (0.14815).
+The PIC18F458 reads the battery voltage and NOT the avionics system bus voltage, which switches between the battery and shore power. It reads an onboard 10bit ADC which is connected to the battery via a resistive voltage divider, which in turn is turned on by a ZXMN2A01F N-channel MOSFET. The divider is R1 = 115K, R2 = 20K which gives a theoretical divide by factor of 0.14815. Thus Vb should be 5/1024/0.14815\*(raw ADC). Since the resistors are only 1%, and the MOSFET adds it's own resistance, we'll simply modify the voltage divider constant (0.14815).
So, Keith wrote a Nickle script to take the CAN message from the APS (APS\_REPORT\_VOLTAGE) and display it on the screen in a nice format (a voltage value). We also connected a Fluke 84 DMM (in high accuracy mode) to the battery directly at the pack via some clip leads.
diff --git a/AvionicsTeamHome.mdwn b/AvionicsTeamHome.mdwn
index 4655891..463e12b 100644
--- a/AvionicsTeamHome.mdwn
+++ b/AvionicsTeamHome.mdwn
@@ -36,8 +36,8 @@ Latest News, Status and "Todo's"
- [[Launch Tower:|Lv2LaunchTowerElectronics]]
- [[Launch Tower Computer (LTC)|Lv2LaunchTowerComputer]]: A Linux-based x86 PC104 stack with Lucent Orinoco 802.11b card and CAN.
- [[24dBi 2.4GHz 802.11b parabolic dish antenna|CommunicationsTeamHome]] ("BBQ" grill antenna).
-- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: [[PIC18F458]]-based CAN node with four relays and some analog sampling.
-- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: [[PIC18F458]]-based board which provides rocketready relay interlock in firing chain.
+- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: PIC18F458-based CAN node with four relays and some analog sampling.
+- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: PIC18F458-based board which provides rocketready relay interlock in firing chain.
- [[Launch Igniter Circuit|Lv2LaunchTowerIgniter]]: igniter circuit for launch igniter.
- [[Umbilical cord|Lv2UmbilicalCord]]: Connects LV2 to the electronics box. Provides shore power, includes rocketready relay interlock.
- [[Launch Tower Power System|Lv2LaunchTowerPower]]:Solar array, charge controller, and battery
diff --git a/BatteryPackLv2.mdwn b/BatteryPackLv2.mdwn
index b05fa8d..47c2031 100644
--- a/BatteryPackLv2.mdwn
+++ b/BatteryPackLv2.mdwn
@@ -21,7 +21,7 @@ We'd love a smart battery to tell us the charge on the batteries. We can get a p
It's exactly what we want - it gives a pulse every n coulumbs of charge in/out of the battery. But, it only goes to 8.5V! After tearing our hair out for a while, we decided we could put it across the bottom two "parallel cell packs" in the [[battery pack|BatteryPackLv2]] and just not worry about it. Sure, it'll draw a maximum of 115 uA off of the lower two batteries and not the top two, but quoting a well known battery pundit: "During discharge @ C/1 the extra draw from the lower two cells is ~115uA \* 3600s = 414mC. The pack capacity is ~4A \* 3600s 14.4kC. The imbalance is 28.75E-6 of pack capacity." So at 30 ppm imbalance, we just don't care. So we can use the IC, even though it won't go across the whole pack.
-There are other chips, but we hate low side current shunts and the I^2 bus (E.g., [http://www.maxim-ic.com/quick\_view2.cfm?qv\_pk=1793&amp;ln=](http://www.maxim-ic.com/quick_view2.cfm?qv_pk=1793&ln=) ). (Actually certain well known battery pundits don't mind low side shunts. They do hate the [[I2C]] bus though. ; )
+There are other chips, but we hate low side current shunts and the I^2 bus (E.g., [http://www.maxim-ic.com/quick\_view2.cfm?qv\_pk=1793&amp;ln=](http://www.maxim-ic.com/quick_view2.cfm?qv_pk=1793&ln=) ). (Actually certain well known battery pundits don't mind low side shunts. They do hate the I2C bus though. ; )
### <a name="Calculating the LTC4150&#39;s shunt"></a><a name="Calculating the LTC4150&#39;s shunt "></a> Calculating the LTC4150's shunt resistor, Rs:
@@ -29,13 +29,13 @@ Rs = 50m V / Imax = 50 mV / 5 A = 0.01 Ohm
The 5 A needs to be justified a bit; in the [[Power consumption in LV2|Lv2PowerUsage]] we draw about 2.8 A. I figure an over estimate of roughly two is right; we may add lots more junk to the rocket, and more importantly, we're charging the battery pack at about 1C which is about 4 A.... so 5 A seems pretty reasonable. It also gives us a nice round shunt resistor (10 milliohms). At 5 A, that's a power rating of (5 A)^2 \* 0.01 ohm \* = 250 mW.
-- Oh oh oh I love this: a four terminal shunt resistor, Ohmite 1% 3W: Digikey [[CS3FR010]]-ND $10.23 (!)
-- Else this weird package Ohmite SMD 1% 1W power resistor: Digikey [[RW1S0BAR010FBK]]-ND $2.53
-- Else Panasonic 2512 1W 1% (+/- 100 ppm tempco): Digikey [[P10MMCT]]-ND $8.16/10
+- Oh oh oh I love this: a four terminal shunt resistor, Ohmite 1% 3W: Digikey CS3FR010-ND $10.23 (!)
+- Else this weird package Ohmite SMD 1% 1W power resistor: Digikey RW1S0BAR010FBK-ND $2.53
+- Else Panasonic 2512 1W 1% (+/- 100 ppm tempco): Digikey P10MMCT-ND $8.16/10
### <a name="Calculating the filter Capacitor"></a> Calculating the filter Capacitors:
-They say use a cermaic 4.7uF and don't give much justification for it; bigger is, of course, better, but since "A 10nA leakage is roughly equivalent to the input offset error of the integrator" the leakage needs to be dealt with. I'd like to check on the Panasonic Multilayer Ceramic Chip Caps (MLCC) - [http://www.panasonic.com/industrial/components/mlcc\_page.htm](http://www.panasonic.com/industrial/components/mlcc_page.htm) - but so far I can't find any kind of leakage info. In particular, the 1206 [[X5R]] 25V 10uF part (Digikey [[PCC2326CT]]-ND)... I'd go with that until we find the leakage current sucks.
+They say use a cermaic 4.7uF and don't give much justification for it; bigger is, of course, better, but since "A 10nA leakage is roughly equivalent to the input offset error of the integrator" the leakage needs to be dealt with. I'd like to check on the Panasonic Multilayer Ceramic Chip Caps (MLCC) - [http://www.panasonic.com/industrial/components/mlcc\_page.htm](http://www.panasonic.com/industrial/components/mlcc_page.htm) - but so far I can't find any kind of leakage info. In particular, the 1206 X5R 25V 10uF part (Digikey PCC2326CT-ND)... I'd go with that until we find the leakage current sucks.
### <a name="The Error Budget"></a> The Error Budget
diff --git a/BatteryResearchLv2.mdwn b/BatteryResearchLv2.mdwn
index 3283f18..8b25114 100644
--- a/BatteryResearchLv2.mdwn
+++ b/BatteryResearchLv2.mdwn
@@ -9,7 +9,7 @@
</tr>
<tr>
<td> Model: </td>
- <td>[[LGQ863448H]]</td>
+ <td>LGQ863448H</td>
</tr>
<tr>
<td> Distributer: </td>
diff --git a/BlockDiagram.mdwn b/BlockDiagram.mdwn
index 7e8b995..7bed280 100644
--- a/BlockDiagram.mdwn
+++ b/BlockDiagram.mdwn
@@ -10,7 +10,7 @@ Our [[FlightComputer]] (FC) is a [PC104](http://www.pc104.org/) form factor 133M
The FC is connected to the rest of the avionics modules using the [[CAN bus (Controller Area Network Bus)|CanBusLinks]], which is a robust 1Mbps priority-arbitrated multi-drop serial bus.
-Each of the small CAN nodes are Microchip's [[PIC18F458]], an 8 bit microcontroller with a CAN protocol peripheral on-chip. Current CAN nodes include:
+Each of the small CAN nodes are Microchip's PIC18F458, an 8 bit microcontroller with a CAN protocol peripheral on-chip. Current CAN nodes include:
- 6DOF Inertial Measurement Unit
- Open Source GPS receiver
diff --git a/CanBusUtilization.mdwn b/CanBusUtilization.mdwn
index 4be0dc6..8075a1d 100644
--- a/CanBusUtilization.mdwn
+++ b/CanBusUtilization.mdwn
@@ -50,9 +50,9 @@ Here's a rough estimate of how many bits CAN messages may use, and what we can e
<font> _Notes: The bit stuffing figures (6, 5, 11) are just guesses and have not been very carefully thought out except that they look right given the general structure of the CAN message. You can also easily calculate the maximum and minimum latencies in transmission since a bit time is 1us._ </font>
-### <a name="LV2A Current Message Rate:"></a> [[LV2A]] Current Message Rate:
+### <a name="LV2A Current Message Rate:"></a> LV2A Current Message Rate:
-Here's the current estimate of the bandwidth needed for the [[LV2A]] system:
+Here's the current estimate of the bandwidth needed for the LV2A system:
<table border=1 cellpadding=0 cellspacing=0>
<tr>
diff --git a/CanNodeFirmwareGps.mdwn b/CanNodeFirmwareGps.mdwn
index 7009368..d7bcd1f 100644
--- a/CanNodeFirmwareGps.mdwn
+++ b/CanNodeFirmwareGps.mdwn
@@ -1,6 +1,6 @@
## <a name="LV2 GPS CAN Node Firmware"></a> LV2 GPS CAN Node Firmware
-This node interfaces a Rockwell AKA Conexant now AKA SiRF "Jupiter" GPS Board (firmware v2.30) to the LV2 CAN bus. The current board is a [[PIC16F877]]+SJA1000 PCB modified to use a [[PIC18F458]].
+This node interfaces a Rockwell AKA Conexant now AKA SiRF "Jupiter" GPS Board (firmware v2.30) to the LV2 CAN bus. The current board is a PIC16F877+SJA1000 PCB modified to use a PIC18F458.
----
diff --git a/CanNodeFirmwareImu.mdwn b/CanNodeFirmwareImu.mdwn
index ddaf379..609ca37 100644
--- a/CanNodeFirmwareImu.mdwn
+++ b/CanNodeFirmwareImu.mdwn
@@ -2,7 +2,7 @@
### <a name="IMU CAN Node Hardware Stuff:"></a> IMU CAN Node Hardware Stuff:
-The IMU CAN node is a [[PIC16F877]]+SJA1000 PCB (from 6/2001) modified to use a [[PIC18F458]] with, of course, an [[IMU|InertialMeasurementUnit]].
+The IMU CAN node is a PIC16F877+SJA1000 PCB (from 6/2001) modified to use a PIC18F458 with, of course, an [[IMU|InertialMeasurementUnit]].
Schematic is attached below.
@@ -53,7 +53,7 @@ Hardware interface:
----
-Attached below is firmware from the IMU calibration project which used a [[PIC16F877]] to sample the the ADC and stream the data over a serial line. It should be a great place to start for writing the IMU interface code.
+Attached below is firmware from the IMU calibration project which used a PIC16F877 to sample the the ADC and stream the data over a serial line. It should be a great place to start for writing the IMU interface code.
- [[imu_firmware.ZIP]]: send/recv can mesg needs more work
diff --git a/CanNodeSectionAppPower.mdwn b/CanNodeSectionAppPower.mdwn
index ef5727c..92a7e30 100644
--- a/CanNodeSectionAppPower.mdwn
+++ b/CanNodeSectionAppPower.mdwn
@@ -8,7 +8,7 @@
Introduction:
-The APS is the power system of the [[LV2A]]'s avionics. It's a pretty simple system of a prototyped power distribution board and a misc. CAN node board. It also has:
+The APS is the power system of the LV2A's avionics. It's a pretty simple system of a prototyped power distribution board and a misc. CAN node board. It also has:
- 2 12V battery packs of made up of 2 2CR5 6V primary Li batteries (think camera batteries).
- a two conductor umbilical cord, which provides shore (external) power to the system as well as serving as a launching system interlock.
diff --git a/CanNodeSectionProcessor.mdwn b/CanNodeSectionProcessor.mdwn
index ecebc30..9a376c5 100644
--- a/CanNodeSectionProcessor.mdwn
+++ b/CanNodeSectionProcessor.mdwn
@@ -1,6 +1,6 @@
# CAN Node Virtual Section: Processor
-We're using the [[PIC18F458]], at 40MHz (if we get the production Silion), at 5V, in a TQFP package. It's a pain to solder, but it's great - everything we want in a TQFP (except for a flat data space. Sigh.).
+We're using the PIC18F458, at 40MHz (if we get the production Silion), at 5V, in a TQFP package. It's a pain to solder, but it's great - everything we want in a TQFP (except for a flat data space. Sigh.).
Data Sheet for the [PIC18F458](http://www.microchip.com/11110/pline/picmicro/category/perictrl/14kbytes/devices/18f458/index.htm).
diff --git a/CanNodes.mdwn b/CanNodes.mdwn
index 822f170..a914486 100644
--- a/CanNodes.mdwn
+++ b/CanNodes.mdwn
@@ -1,6 +1,6 @@
# <a name="LV2 CAN Nodes"></a> LV2 CAN Nodes
-LV2 consists of a main processor - the "[[Flight Computer|FlightComputer]]" which is a 586 PC-104 board - and a dozen tiny little boards strung out on the [[CAN bus|CanBusLinks]]. These dozens of little boards are each run by a small microcontroller (currently the [[PIC18F458]]) and perform all of the sensing and actuation for the vehicle.
+LV2 consists of a main processor - the "[[Flight Computer|FlightComputer]]" which is a 586 PC-104 board - and a dozen tiny little boards strung out on the [[CAN bus|CanBusLinks]]. These dozens of little boards are each run by a small microcontroller (currently the PIC18F458) and perform all of the sensing and actuation for the vehicle.
Since each of the boards has the same microcontroller, we've decided to break the nodes up into virtual "sections". Each section is a schematic and layout all to itself; using a common interconnect pattern, these layouts are then laid next to each other by a [[Gerber editor application|GerberTools]]. It's a clever way to eek some professional quality features from a shareware program (EAGLE).
@@ -9,7 +9,7 @@ Since each of the boards has the same microcontroller, we've decided to break th
<table border=1 cellpadding=0 cellspacing=0>
<tr>
<td>[[CanNodeSectionProcessor]]</td>
- <td> The section with the [[PIC18F458]], 12 to 5V switching power supply, oscillator, an optional Vref and ICD plug-in. </td>
+ <td> The section with the PIC18F458, 12 to 5V switching power supply, oscillator, an optional Vref and ICD plug-in. </td>
</tr>
<tr>
<td>[[CanNodeSectionInterface]]</td>
@@ -70,7 +70,7 @@ Since each of the boards has the same microcontroller, we've decided to break th
[[ICD2 to CAN Node cabling|IcdToMolex]] information
-## <a name="Used _PIC18F458 Pins"></a> Used [[PIC18F458]] Pins
+## <a name="Used _PIC18F458 Pins"></a> Used PIC18F458 Pins
The "next generation" PIC nodes are converging to a single design, with a neat little CAN connector, switched power supply (SPS) and for critical nodes, a highly-available power supply (HAP). Also, all nodes must have an oscillator, ICD2 pins, MCLR, etc.
diff --git a/CantalopeHardware.mdwn b/CantalopeHardware.mdwn
index cef5135..32f6aca 100644
--- a/CantalopeHardware.mdwn
+++ b/CantalopeHardware.mdwn
@@ -6,7 +6,7 @@
Here's the first cut at CANtalope hardware.
-We're using a MISC\_NODE1 PCB which is a basically a small, weirdly dimensioned PCB with a [[PIC18F458]], CAN transciever, and 0.1" prototyping space.
+We're using a MISC\_NODE1 PCB which is a basically a small, weirdly dimensioned PCB with a PIC18F458, CAN transciever, and 0.1" prototyping space.
LEDS:
diff --git a/CurrentBringList.mdwn b/CurrentBringList.mdwn
index 6f17982..ab1320a 100644
--- a/CurrentBringList.mdwn
+++ b/CurrentBringList.mdwn
@@ -764,7 +764,7 @@ _On Launch Control (LC) table:_
</tr>
</table>
-_TrackMaster 2000 ([[TM2K]]):_
+_TrackMaster 2000 (TM2K):_
<table border=1 cellpadding=0 cellspacing=0>
<tr>
@@ -781,19 +781,19 @@ _TrackMaster 2000 ([[TM2K]]):_
</tr>
<tr>
<td align="center"> * </td>
- <td>[[TM2K]] to LC 802.11b cable </td>
+ <td>TM2K to LC 802.11b cable </td>
<td> - </td>
<td> 20&#39; </td>
</tr>
<tr>
<td align="center"> * </td>
- <td>[[TM2K]] to LC ATV cable </td>
+ <td>TM2K to LC ATV cable </td>
<td> - </td>
<td> 20&#39;: also has N to F adapter, F-to-F DC block </td>
</tr>
<tr>
<td align="center"> * </td>
- <td>[[TM2K]] to LC APP power cable </td>
+ <td>TM2K to LC APP power cable </td>
<td> - </td>
<td> 30&#39; </td>
</tr>
diff --git a/GroundSupport.mdwn b/GroundSupport.mdwn
index 7c01a63..ad0498d 100644
--- a/GroundSupport.mdwn
+++ b/GroundSupport.mdwn
@@ -4,17 +4,17 @@ The important components of the ground support systems are [[LaunchControl]], [[
## <a name="Telemetry"></a> <a name="Telemetry">Telemetry</a>
-[[LV1B]]'s telemetry downlink was a 19.2Kbps downlink-only radio modem transmitting a [[custom protocol|GroundSupport/LV1BTelemetryPacketSpec.html]]. The recieving end on the ground logged all of the data for later analysis, and displayed a slightly-processed subset of the information in a graphical interface called RocketView. For LV2, we'd like to use a faster connection for telemetry, particularly [[WiFi]].
+LV1B's telemetry downlink was a 19.2Kbps downlink-only radio modem transmitting a [[custom protocol|GroundSupport/LV1BTelemetryPacketSpec.html]]. The recieving end on the ground logged all of the data for later analysis, and displayed a slightly-processed subset of the information in a graphical interface called RocketView. For LV2, we'd like to use a faster connection for telemetry, particularly [[WiFi]].
The important components of the telemetry system are the [[FlightComputerSoftware]] and the [[RocketView]].
> Changing how we get our telemetry to the ground doesn't mean we can't reuse
>
-> [[LV1B]]
+> LV1B
>
> 's protocol and Rocketview, but I think at least the protocol is worth replacing. Our experience with the protocol we designed for
>
-> [[LV1B]]
+> LV1B
>
> was that it was relatively complex to implement a decoder for it. Since we have a new network protocol which carries all of the information our telemetry should have (see
>
diff --git a/HybridBudget.mdwn b/HybridBudget.mdwn
index 96ea69c..dd38915 100644
--- a/HybridBudget.mdwn
+++ b/HybridBudget.mdwn
@@ -55,7 +55,7 @@
<tr>
<td> Nitrogen Flow Gauge Regulator </td>
<td> Smith </td>
- <td>[[H1103B]] Flowmeter </td>
+ <td>H1103B Flowmeter </td>
<td> on loan </td>
<td> N/A </td>
</tr>
@@ -117,7 +117,7 @@
<tr>
<td> DAQ Board </td>
<td> Flextek </td>
- <td>[[FC1F010]] Flex controller </td>
+ <td>FC1F010 Flex controller </td>
<td> manufacturer </td>
<td> $49.95 </td>
</tr>
diff --git a/HybridSequencer.mdwn b/HybridSequencer.mdwn
index a6f344f..988ddf9 100644
--- a/HybridSequencer.mdwn
+++ b/HybridSequencer.mdwn
@@ -13,7 +13,7 @@ The Hybrid Sequencer program has two primary functions:
1. Automated control the digital output channels of the [[Flex Bus and Interface board|HybridSequencer/flexandinterface.jpg]] to activate and deactivate them at the appropriate times thus turning on and off the solenoids for the oxidizer, purge and igniter functions. <br />
2. Serve as a manual interface with the Flex Bus and Interface board to select the digital output channels as required through the ‘Test Panel’ buttons.
-The [[FC1F010]] is a multi-function microcontroller with a modest amount of Digital I/O and Analog to Digital converters
+The FC1F010 is a multi-function microcontroller with a modest amount of Digital I/O and Analog to Digital converters
The Flex Bus microcontroller is designed to be easily programmed with Visual Basic and utilizes an Active X component named [[EZX.ocx|HybridSequencer/exz1.jpg]] (“FTView” for newer versions) which handles the interface between the Visual Basic program and the microcontroller hardware. This Active X control can be downloaded from the Flex Tek website [[or here |HybridSequencer/EZX.ocx]] and can be inserted as a Control Component in your Visual Basic project.
diff --git a/LinkBudget.mdwn b/LinkBudget.mdwn
index 271aa23..1138c4a 100644
--- a/LinkBudget.mdwn
+++ b/LinkBudget.mdwn
@@ -137,7 +137,7 @@ ATV
- Also see System Operating Margin [(SOM)](http://www.ydi.com/calculation/index.php) described by <cite>® Young Design, Inc.</cite>. Their calculator is very useful. Actually the calculators have been moved to the Terabeam Wireless site: [Calculators](http://www.terabeam.com/support/calculations/index.php)
-- The P number system is a metric for picture quality. P5 is best "closed circuit quality", and P1 is barely descernable. See ARRL Handbook. Tom O'Hara [[W6ORG]] provided the signal strength information needed for various P levels.
+- The P number system is a metric for picture quality. P5 is best "closed circuit quality", and P1 is barely descernable. See ARRL Handbook. Tom O'Hara W6ORG provided the signal strength information needed for various P levels.
- The units of dBm at the transmitter is the only place where reference to milliwatts is applied. All other dB values are unitless ratios, thereby the final result is in dBm.
@@ -180,4 +180,4 @@ ATV
### <a name="References"></a> References
-ARRL Handbook<br /> Antenna Engineering Handbook<br /> SMAD III<br /> Tom O'Hara [[W6ORG]]; Signal strength needed for ATV
+ARRL Handbook<br /> Antenna Engineering Handbook<br /> SMAD III<br /> Tom O'Hara W6ORG; Signal strength needed for ATV
diff --git a/ListOfPCMCIABoards.mdwn b/ListOfPCMCIABoards.mdwn
index a8465a5..df069fd 100644
--- a/ListOfPCMCIABoards.mdwn
+++ b/ListOfPCMCIABoards.mdwn
@@ -104,7 +104,7 @@
<table border=1 cellpadding=0 cellspacing=0>
<tr>
<th bgcolor="#99CCCC"><strong> Name </strong></th>
- <td align="right">[[MicroSpace]] PC/104 [[MSMJ104D]] - <a href="http://www.adlogic-pc104.com/msmj104d.html#top" target="_top">http://www.adlogic-pc104.com/msmj104d.html#top</a></td>
+ <td align="right">[[MicroSpace]] PC/104 MSMJ104D - <a href="http://www.adlogic-pc104.com/msmj104d.html#top" target="_top">http://www.adlogic-pc104.com/msmj104d.html#top</a></td>
</tr>
<tr>
<th bgcolor="#99CCCC"><strong> Manufacturer </strong></th>
diff --git a/LoadCellAmp.mdwn b/LoadCellAmp.mdwn
index d5f8282..ed1c925 100644
--- a/LoadCellAmp.mdwn
+++ b/LoadCellAmp.mdwn
@@ -8,7 +8,7 @@ We have acquired a conventional 250 pound tension / compression load cell [(LPU-
[[LoadCellAmpSchematic.png]]
-Referring to the schematic, the [[INA125P]] instrumentation amplifier (U1) does most of the work. It amplifies the approximately 30mV full scale signal into the required 0-5V range. U1 also includes an accurate 1.24V reference and buffer amplifier. These are used to drive a low drop out 3-terminal regulator (U3) to produce a stable 8.75V excitation for the strain gage. 8.75V was chosen as opposed to the more conventional 10V because we may want to run this amplifier on 12VDC and therefore require the extra headroom. Running the bridge at the lower voltage does degrade the signal somewhat (~14%), but this is regarded as acceptable for this application.
+Referring to the schematic, the INA125P instrumentation amplifier (U1) does most of the work. It amplifies the approximately 30mV full scale signal into the required 0-5V range. U1 also includes an accurate 1.24V reference and buffer amplifier. These are used to drive a low drop out 3-terminal regulator (U3) to produce a stable 8.75V excitation for the strain gage. 8.75V was chosen as opposed to the more conventional 10V because we may want to run this amplifier on 12VDC and therefore require the extra headroom. Running the bridge at the lower voltage does degrade the signal somewhat (~14%), but this is regarded as acceptable for this application.
The LT1635 (U2) is an improved LM10 opamp with voltage reference. In this circuit U2 provides a stable pseudo-ground reference level to keep the output signal from clipping against ground even for worst case input offset error. This offset also allows us to read small tension loads if we need to.
diff --git a/Lv2LaunchTowerElectronics.mdwn b/Lv2LaunchTowerElectronics.mdwn
index e4cccbb..3679801 100644
--- a/Lv2LaunchTowerElectronics.mdwn
+++ b/Lv2LaunchTowerElectronics.mdwn
@@ -10,8 +10,8 @@ This includes:
- [[Launch Tower Computer (LTC)|Lv2LaunchTowerComputer]]: A Linux-based x86 PC104 stack with Lucent Orinoco 802.11b card and CAN.
- [[24dBi 2.4GHz 802.11b parabolic dish antenna|CommunicationsTeamHome]] ("BBQ" grill antenna).
-- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: [[PIC18F458]]-based CAN node with four relays and some analog sampling.
-- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: [[PIC18F458]]-based board which provides rocketready relay interlock in firing chain.
+- [[Launch Tower Relay (LTR) board|Lv2LaunchTowerRelay]]: PIC18F458-based CAN node with four relays and some analog sampling.
+- [[RocketReady Relay (RRR) board|Lv2RocketReadyRelay]]: PIC18F458-based board which provides rocketready relay interlock in firing chain.
- [[Launch Igniter Circuit|Lv2LaunchTowerIgniter]]: igniter circuit for launch igniter.
- [[Umbilical cord|Lv2UmbilicalCord]]: Connects LV2 to the electronics box. Provides shore power, includes rocketready relay interlock.
- [[Launch Tower Power System|Lv2LaunchTowerPower]]:Solar array, charge controller, and battery
diff --git a/Lv2LaunchTowerRelay.mdwn b/Lv2LaunchTowerRelay.mdwn
index 2289e79..0100f5d 100644
--- a/Lv2LaunchTowerRelay.mdwn
+++ b/Lv2LaunchTowerRelay.mdwn
@@ -6,7 +6,7 @@
</center>
</div>
-**Overview:** This board has a [[PIC18F458]] (running [[PicCore]]) which runs four relays in the launch tower electronics box and interfaces to the [[LTC|Lv2LaunchTowerComputer]] via the CAN bus. It also has some analog ports available for thermistors, and a lot of expansion room for daughterboards and whatnot.
+**Overview:** This board has a PIC18F458 (running [[PicCore]]) which runs four relays in the launch tower electronics box and interfaces to the [[LTC|Lv2LaunchTowerComputer]] via the CAN bus. It also has some analog ports available for thermistors, and a lot of expansion room for daughterboards and whatnot.
## <a name="Hardware Notes."></a> Hardware Notes.
diff --git a/LvTwoAmateurTelevisionOverview.mdwn b/LvTwoAmateurTelevisionOverview.mdwn
index f9a26fd..78c7271 100644
--- a/LvTwoAmateurTelevisionOverview.mdwn
+++ b/LvTwoAmateurTelevisionOverview.mdwn
@@ -26,7 +26,7 @@ The LV2's ATV system consists of:
</tr>
<tr>
<td> 08/26/2002 </td>
- <td> Decided that we can use IRF&#39;s [[IPS511S]] (Rdson = 80mOhm) for the camera (which only uses 220mA) and overlay board, but we should use the [[IPS5451S]] (Rdson = 6mOhm) for the ATV transmitter and PA which may draw as much as 2 amps. Datasheets below. Did a Digikey order to get them... also got some &quot;surfboards&quot; to mount the SMT DD packages into a 0.1&quot; protoboard. </td>
+ <td> Decided that we can use IRF&#39;s IPS511S (Rdson = 80mOhm) for the camera (which only uses 220mA) and overlay board, but we should use the IPS5451S (Rdson = 6mOhm) for the ATV transmitter and PA which may draw as much as 2 amps. Datasheets below. Did a Digikey order to get them... also got some &quot;surfboards&quot; to mount the SMT DD packages into a 0.1&quot; protoboard. </td>
</tr>
<tr>
<td> 08/27/2002 </td>
diff --git a/PicCore.mdwn b/PicCore.mdwn
index 0b14241..ca9a647 100644
--- a/PicCore.mdwn
+++ b/PicCore.mdwn
@@ -1,4 +1,4 @@
-## <a name="PicCore: A Framework for Microch"></a><a name="_PicCore: A Framework for Microc"></a> PicCore: A Framework for Microchip's [[PIC18FXXX]] Series Microcontrollers
+## <a name="PicCore: A Framework for Microch"></a><a name="_PicCore: A Framework for Microc"></a> PicCore: A Framework for Microchip's PIC18FXXX Series Microcontrollers
### <a name="Introduction"></a> Introduction
diff --git a/PicCore/blog.mdwn b/PicCore/blog.mdwn
index 591d717..48afac8 100644
--- a/PicCore/blog.mdwn
+++ b/PicCore/blog.mdwn
@@ -50,10 +50,10 @@ Left to do: fix CAN receive, test serial routines, implement more peripheral rou
Renamed main folder to c:\\firmware to be more generic. Moved all framework files to the directory "piccore" and formally declared it a framework... whatever that means. Now the user doesn't need to touch anything in that directory and all modification is done in the root ("firmware") directory of their project.
-### <a name="2002/07/05: _LV2CORE"></a> 2002/07/05: [[LV2CORE]]
+### <a name="2002/07/05: _LV2CORE"></a> 2002/07/05: LV2CORE
First compiling code, after switching to HITECH PICC-18. Thanks, HITECH.
-### <a name="2002/06/23: _LV2CORE"></a> 2002/06/23: [[LV2CORE]]
+### <a name="2002/06/23: _LV2CORE"></a> 2002/06/23: LV2CORE
First public release, using MPLAB C18. Doesn't compile.
diff --git a/PicCore/docs.mdwn b/PicCore/docs.mdwn
index d4c1731..99c86cf 100644
--- a/PicCore/docs.mdwn
+++ b/PicCore/docs.mdwn
@@ -2,7 +2,7 @@
## <a name="30 Second Overview"></a> 30 Second Overview
-[[PicCore]] is a collection of C modules which exist in a single direcotry called (surprise) `/piccore`. A single `#include` is added to your code which links in all the various [[PicCore]] routines and datastructures. [[PicCore]] is highly configurable using a single configuration file which uses #defines to include or exclude portions of the code (a la the [eCos](http://sources.redhat.com) RTOS). Also, peripherals are included or not based on the type of processor you have (for example, the CAN functions are included for the [[PIC18Fxx8]] micros but not the [[PIC18FXX2]] micros). Features currently include:
+[[PicCore]] is a collection of C modules which exist in a single direcotry called (surprise) `/piccore`. A single `#include` is added to your code which links in all the various [[PicCore]] routines and datastructures. [[PicCore]] is highly configurable using a single configuration file which uses #defines to include or exclude portions of the code (a la the [eCos](http://sources.redhat.com) RTOS). Also, peripherals are included or not based on the type of processor you have (for example, the CAN functions are included for the PIC18Fxx8 micros but not the PIC18FXX2 micros). Features currently include:
1. Application code (that's your code) doesn't touch the [[PicCore]] directory, so multiple projects can use the same [[PicCore]] folder.
2. CAN initialize, transmit and receive drivers and queues (circular FIFO's)
diff --git a/PicCore/docs/errors.mdwn b/PicCore/docs/errors.mdwn
index e274d62..fe4e5e3 100644
--- a/PicCore/docs/errors.mdwn
+++ b/PicCore/docs/errors.mdwn
@@ -2,7 +2,7 @@
## <a name="Introduction"></a> Introduction
-Handling errors on a PIC is no easy thing to do. In fact, it sucks: there's no stdout - the UART is as close as you can get. But often you don't have access to the UART. You've got a single stinkin' LED. Or maybe you have an [[I2C]] to serial interface? or just the CAN bus? Who knows, and [[PicCore]] certainly doesn't. So the error routines here are meant to log and store errors in a useful way: _it's up to the application code to decide what to do with the errors, and get the errors out to the user._
+Handling errors on a PIC is no easy thing to do. In fact, it sucks: there's no stdout - the UART is as close as you can get. But often you don't have access to the UART. You've got a single stinkin' LED. Or maybe you have an I2C to serial interface? or just the CAN bus? Who knows, and [[PicCore]] certainly doesn't. So the error routines here are meant to log and store errors in a useful way: _it's up to the application code to decide what to do with the errors, and get the errors out to the user._
There are two arrays of uint8\_t's called `piccore_error_log[]` and `piccore_error_count_log[]`. Together, they make a 12 bit status register for each type of error. Think of them as a single an indexed array, where the index is the **_error number_**. Meaning, if I log an error #34, `piccore_error_log[34]` and `piccore_error_log[34/2]` (more on the divide-by-2 below) is where that fact is stored.
diff --git a/PsasCantalopePage.mdwn b/PsasCantalopePage.mdwn
index a283781..54bdfe8 100644
--- a/PsasCantalopePage.mdwn
+++ b/PsasCantalopePage.mdwn
@@ -4,6 +4,6 @@ CANtalope is a very, very crude CAN bus monitor meant to interface a PC's serial
[[CANtalope Software|CantalopeSoftware]]: The software on the PC side is a Linux-based CLI tool which allows us to translate the binary flow of information from the CANtalope boards to the PC. There's also some custom CANtalope commands.
-[[CANtalope Hardware|CantalopeHardware]]: The hardware is a Microchip [[PIC18F458]] microcontroller with onboard CAN peripheral and UART. Why are we using those? Because we have a ton of them from the LV2 avionics sytem. They don't make a particularly good CAN analyzers, but they do make a decent CAN bus monitor... i.e., getting messages on and off the bus to a PC.
+[[CANtalope Hardware|CantalopeHardware]]: The hardware is a Microchip PIC18F458 microcontroller with onboard CAN peripheral and UART. Why are we using those? Because we have a ton of them from the LV2 avionics sytem. They don't make a particularly good CAN analyzers, but they do make a decent CAN bus monitor... i.e., getting messages on and off the bus to a PC.
[[CANtalope firmware|CantalopeFirmware]]: The firmware on the PICs is a custom application running under the [[PicCore]] framework.
diff --git a/PsasRoadMap.mdwn b/PsasRoadMap.mdwn
index e4c728f..e61cbed 100644
--- a/PsasRoadMap.mdwn
+++ b/PsasRoadMap.mdwn
@@ -73,7 +73,7 @@ Here's a proposed 5-year plan for PSAS. It's just a guideline to help us figure
## <a name="Milestone 11:"></a> Milestone 11:
-- [[L4B]]/LV5 suborbital multistaged rocket with active guidance
+- L4B/LV5 suborbital multistaged rocket with active guidance
- All of the complexity of an orbital vehicle but not the size
- Orbital altitude but not velocity &gt; 200km (&gt;120mi)
diff --git a/RecoveryNodeLV2.mdwn b/RecoveryNodeLV2.mdwn
index 4770d31..d075fa0 100644
--- a/RecoveryNodeLV2.mdwn
+++ b/RecoveryNodeLV2.mdwn
@@ -84,7 +84,7 @@ The As-Built specs for v1.2 are:
[[LV2-Recovery_Block-0.0.png]]
-Referring to the block diagram, the circuit is divided into sections, namely the CORE, HAP, DTMF and PYRO sections. The CORE section contains the CAN bus interface which includes the main 14V DC power bus as well as the two wire CAN communications interface. The CORE section has a [[PIC18F458]] microprocessor and a 1.54MHz switching power supply [SPS] to convert the main bus power down to 5 Volts. The intention is to re-use the CORE section for all new LV2 CAN nodes.
+Referring to the block diagram, the circuit is divided into sections, namely the CORE, HAP, DTMF and PYRO sections. The CORE section contains the CAN bus interface which includes the main 14V DC power bus as well as the two wire CAN communications interface. The CORE section has a PIC18F458 microprocessor and a 1.54MHz switching power supply [SPS] to convert the main bus power down to 5 Volts. The intention is to re-use the CORE section for all new LV2 CAN nodes.
To the right of the CORE section is the HAP which stands for High Availability Power supply. The HAP contains another 1.54MHz switching power supply operating in boost mode. This supply provides a 5V output using either the CORE SPS voltage or a single cell rechargeable lithium battery as input. The HAP automatically switches to battery power when the SPS power fails. In the battery backup [BB] section of the HAP there are charging, monitoring and over voltage protection circuits for the lithium battery
diff --git a/SjaCanTestNode.mdwn b/SjaCanTestNode.mdwn
index d83fc6c..53d2c65 100644
--- a/SjaCanTestNode.mdwn
+++ b/SjaCanTestNode.mdwn
@@ -1,6 +1,6 @@
-# <a name="PIC16F877/SJA1000 CAN Test Node"></a><a name="PIC16F877/SJA1000 CAN Test Node "></a> [[PIC16F877]]/SJA1000 CAN Test Node Information
+# <a name="PIC16F877/SJA1000 CAN Test Node"></a><a name="PIC16F877/SJA1000 CAN Test Node "></a> PIC16F877/SJA1000 CAN Test Node Information
-Our first version of CAN nodes had a Microchip [[PIC16F877]] and a Philips SJA1000 CAN protocol chip on it. We made a "test" node, so the FC people would have a working CAN node in order to test the CAN driver and and FC software.
+Our first version of CAN nodes had a Microchip PIC16F877 and a Philips SJA1000 CAN protocol chip on it. We made a "test" node, so the FC people would have a working CAN node in order to test the CAN driver and and FC software.
## <a name="Hooking it up"></a> Hooking it up
diff --git a/SmartBatteriesLv2.mdwn b/SmartBatteriesLv2.mdwn
index 39aabf1..ad39cbe 100644
--- a/SmartBatteriesLv2.mdwn
+++ b/SmartBatteriesLv2.mdwn
@@ -12,7 +12,7 @@ This future node has three main functions:
Here's what we imagine it to be:
-- A standard CAN Node (a [[PIC18F458]] hooked to the CAN and power buses).
+- A standard CAN Node (a PIC18F458 hooked to the CAN and power buses).
- One or two Li-ion Smart Battery (i.e., onboard battery monitoring hardware)
- A level 2 or 3 Smart Battery charger (talks SMBus (I^2C) with the battery - e.g., the Linear LTC1759 SMB charger IC).
- Processor listens in on charger/battery conversation, gives commands as necessary and relays information to CAN bus.
diff --git a/Sponsors.mdwn b/Sponsors.mdwn
index 1a4d675..9888540 100644
--- a/Sponsors.mdwn
+++ b/Sponsors.mdwn
@@ -14,5 +14,5 @@
- [Powerstream, Inc.](http://www.powerstream.com) - 2x 19V @ 4A AC/DC power supplies and a 12V to 19V @ 4A DC-DC converter.
- [ANSOFT, INC](http://www.ansoft.com) - use of their HFSS RF modeling tool (as well as their older "Clementine" program).
- [HI-TECH Software](http://www.htsoft.com) - 4 seats of the excellent PICC-18 PIC 18 core cross-compiler.
-- [Microchip, Inc.](http://www.microchip.com) - use of beta silicon of the [[PIC18F458]] and _extensive_ support.
+- [Microchip, Inc.](http://www.microchip.com) - use of beta silicon of the PIC18F458 and _extensive_ support.
- [Paratech Parachutes](http://www.paratech-parachutes.com/) - for the design and construction of parachutes for LV2.
diff --git a/TheoryOfOperation.mdwn b/TheoryOfOperation.mdwn
index 687ff97..672d30c 100644
--- a/TheoryOfOperation.mdwn
+++ b/TheoryOfOperation.mdwn
@@ -42,7 +42,7 @@ Once the system has cooled. We can remove the forward nozzle-retaining flange an
</tr>
<tr>
<td> I/O board </td>
- <td>[[FC1F010]] Flex Controller </td>
+ <td>FC1F010 Flex Controller </td>
<td><a href="http://www.flex-tek.com/FTman10.pdf" target="_top">http://www.flex-tek.com/FTman10.pdf</a></td>
</tr>
<tr>
@@ -101,7 +101,7 @@ Once the system has cooled. We can remove the forward nozzle-retaining flange an
</tr>
<tr>
<td> Nitrogen Regulator </td>
- <td> Smith [[H1103B]] Flowmeter </td>
+ <td> Smith H1103B Flowmeter </td>
<td>
</td>
</tr>
diff --git a/UplinkLv1.mdwn b/UplinkLv1.mdwn
index 7454a1e..6bb032c 100644
--- a/UplinkLv1.mdwn
+++ b/UplinkLv1.mdwn
@@ -14,7 +14,7 @@ In order to guarantee that we reached the rocket, we used an old 50W Motorola Mo
**[[2m FM Radio Receiver|LvOneUplinkReceiver]]**
-The 146.430MHz signal is picked up by a 1/4 wavelength ground plane antenna located in the nosecone. The signal is demodulated by a Motorola MC13135 FM Receiver IC (<http://e-www.motorola.com/brdata/PDFDB/docs/MC13135.pdf>). We had to enclose the receiver and power supply ([[LM78L05]]) in it's own PCB box since it was very susceptable to being swamped by the other RF transmitters in the avionics. Even bringing out the RSSI lead caused the receiver to be swamped by noise. After careful shielding, the receiver worked with no problems. We even tested it over ~ 7 miles from Council Crest to Powell Butte (see the old meeting notes for the test).
+The 146.430MHz signal is picked up by a 1/4 wavelength ground plane antenna located in the nosecone. The signal is demodulated by a Motorola MC13135 FM Receiver IC (<http://e-www.motorola.com/brdata/PDFDB/docs/MC13135.pdf>). We had to enclose the receiver and power supply (LM78L05) in it's own PCB box since it was very susceptable to being swamped by the other RF transmitters in the avionics. Even bringing out the RSSI lead caused the receiver to be swamped by noise. After careful shielding, the receiver worked with no problems. We even tested it over ~ 7 miles from Council Crest to Powell Butte (see the old meeting notes for the test).
The receiver outputs a 1vpp audio frequency signal, which should contain the DTMF tones and any other communications traffice on that frequency.
@@ -24,7 +24,7 @@ The demodulated audio signal is then send to a Holtek HT9170 DTMF decoder chip (
**Microcontroller**
-We used the Microchip [[PIC16F84]] (<http://www.microchip.com/download/lit/pline/picmicro/families/16f8x/30430c.pdf>), a small (18pin DIP) 4MHz RISC microcontroller, to decode the DTMF nibble and output enable bit from the Holtek decoder. The PIC read in the nibble every time the enable line was lowered and used the nibble received in a state machine to determine what to do. The state machine screened for the password and command while allowing for repetitions in the nibble (we assumed long dropouts would look like repeated key presses).
+We used the Microchip PIC16F84 (<http://www.microchip.com/download/lit/pline/picmicro/families/16f8x/30430c.pdf>), a small (18pin DIP) 4MHz RISC microcontroller, to decode the DTMF nibble and output enable bit from the Holtek decoder. The PIC read in the nibble every time the enable line was lowered and used the nibble received in a state machine to determine what to do. The state machine screened for the password and command while allowing for repetitions in the nibble (we assumed long dropouts would look like repeated key presses).
We required a simple password - a "#" followed by a "\*" - and then a command 0 - 9. Only three commands (numbers) directly applied to the PIC - fire the recovery igniter, fire the camera shroud igniter, and reset the igniter outputs. The igniter circuitry uses a simple NPN transistor driving a PNP Darlington in a TO220 case to fire the igniters. The igniters used were "Estes" brand igniters, but substantially modified to increase reliability.
diff --git a/news/1999-04-11/data.mdwn b/news/1999-04-11/data.mdwn
index b88da4f..6dd9dea 100644
--- a/news/1999-04-11/data.mdwn
+++ b/news/1999-04-11/data.mdwn
@@ -1,6 +1,6 @@
# <a name="LV1 Flight Data from April 11th,"></a> LV1 Flight Data from April 11th, 1999
-From the original flight of LV1, with the LV1 [[PIC17C74]] flight computer and no low pass filters (!) or anything on the LV1 IMU. Yeeeuch.
+From the original flight of LV1, with the LV1 PIC17C74 flight computer and no low pass filters (!) or anything on the LV1 IMU. Yeeeuch.
Here's some comments from the original assembly code on the raw data output:
diff --git a/news/2000-10-07/data.mdwn b/news/2000-10-07/data.mdwn
index c3c5ae9..2afce3e 100644
--- a/news/2000-10-07/data.mdwn
+++ b/news/2000-10-07/data.mdwn
@@ -3,7 +3,7 @@
Attached below is the raw data from the launch. We'll start to post updates on this page as we get them... we're still working on this.
<div>
- <center>[[lv1b_imu_raw_data_graph.gif]]<br><font size="-1"> <em>Raw Data from 2000/10/07 [[LV1B]] flight: values in raw 12 bit ADC counts, 0 - 4096</em> </font><br>
+ <center>[[lv1b_imu_raw_data_graph.gif]]<br><font size="-1"> <em>Raw Data from 2000/10/07 LV1B flight: values in raw 12 bit ADC counts, 0 - 4096</em> </font><br>
<br>
- <br>[[GPS_Only_Animated_from_telemetry.gif]]<br><font size="-1"> <em>GPS data from the 2000/10/07 [[LV1B]] flight in the Local Tangent Plane (NED): note the whacked points after the recovery charge is fired</em> </font></center>
+ <br>[[GPS_Only_Animated_from_telemetry.gif]]<br><font size="-1"> <em>GPS data from the 2000/10/07 LV1B flight in the Local Tangent Plane (NED): note the whacked points after the recovery charge is fired</em> </font></center>
</div>
diff --git a/news/2001-08-02.mdwn b/news/2001-08-02.mdwn
index db358e7..a6ec786 100644
--- a/news/2001-08-02.mdwn
+++ b/news/2001-08-02.mdwn
@@ -12,7 +12,7 @@ We discussed and scetched out the layout of the avionics bay. We want the Batter
**Umbilical and ground support circuitry**
-That brought us to a discussion of the Umbilical. We want to avoid a Nasa-ized solution with rotating/retracting/failing parts. For [[LV1B]] the umbilical was simply some contacts taped to the side of the rocket with conducting tape. The rocket skin had a spot with conductive plates. If someone has a better solution we are all ears!
+That brought us to a discussion of the Umbilical. We want to avoid a Nasa-ized solution with rotating/retracting/failing parts. For LV1B the umbilical was simply some contacts taped to the side of the rocket with conducting tape. The rocket skin had a spot with conductive plates. If someone has a better solution we are all ears!
Oh, Yeah...I'm going to ad sketches of this stuff, but I need to get the GIMP up, and draw it!
diff --git a/news/2001-08-15.mdwn b/news/2001-08-15.mdwn
index 4bcd35a..bf8bf9a 100644
--- a/news/2001-08-15.mdwn
+++ b/news/2001-08-15.mdwn
@@ -21,8 +21,8 @@ In attendance: Bart, Nathan, Jamey, Andrew, Larry, Dennis.
**CAN Nodes:**
-- Found a brand new 68HC11-like microcontroller for the CAN nodes! It's the [[MC9S12DP256]] - a 68HC12 (which is a 16bit 68HC11) with 256k FLASH, 32K RAM, CAN, timers, ADCs, etc!! Of course - it's brand new and they're out of samples so we can't get it until January. Surprise!
-- Which brings us to: We're officially going with the [[PIC16F877]] w/ SJA1000 solution. The first generation PCB is done, I'll do another rev next week, and the damn thing will be done.
+- Found a brand new 68HC11-like microcontroller for the CAN nodes! It's the MC9S12DP256 - a 68HC12 (which is a 16bit 68HC11) with 256k FLASH, 32K RAM, CAN, timers, ADCs, etc!! Of course - it's brand new and they're out of samples so we can't get it until January. Surprise!
+- Which brings us to: We're officially going with the PIC16F877 w/ SJA1000 solution. The first generation PCB is done, I'll do another rev next week, and the damn thing will be done.
----
diff --git a/news/2002-02-06.mdwn b/news/2002-02-06.mdwn
index a5d6f49..440cc3e 100644
--- a/news/2002-02-06.mdwn
+++ b/news/2002-02-06.mdwn
@@ -40,7 +40,7 @@ Avionics Team:
- Some thoughts:
- Can we put together 802.11b cards w/different antennas? Binkley might be able to help.
- Use Binkley’s antenna?
- - Can we connect the smart battery and charger directly to the FC via the onboard [[I2C]] bus? We could then you Linux's built in ACPI stuff (possibly - depends on charge controller).
+ - Can we connect the smart battery and charger directly to the FC via the onboard I2C bus? We could then you Linux's built in ACPI stuff (possibly - depends on charge controller).
Propulstion Team:
diff --git a/news/2002-02-27.mdwn b/news/2002-02-27.mdwn
index c4ce4fb..a64da20 100644
--- a/news/2002-02-27.mdwn
+++ b/news/2002-02-27.mdwn
@@ -12,7 +12,7 @@
- Debian 'woody', ext3 journaled filesystems, Linux 2.4.17 std 686 binary distribution
- sudo, sshd, exim, mailman, twiki, apache
- Hardware:
- - Celeron 366, oddball motherboard (440BX-based), 128MB RAM, 3.2GB IDE disk, [[FA310TX]] ethernet, 24X cdrom
+ - Celeron 366, oddball motherboard (440BX-based), 128MB RAM, 3.2GB IDE disk, FA310TX ethernet, 24X cdrom
**CAN Nodes:**
diff --git a/news/2002-04-07.mdwn b/news/2002-04-07.mdwn
index a159646..2bb2edc 100644
--- a/news/2002-04-07.mdwn
+++ b/news/2002-04-07.mdwn
@@ -16,7 +16,7 @@ We were concerned about the precision reference necessary to acheive less than 1
**Tuning Local Oscillators:**
-First we talked about tuning the local oscillators: in our case, the [[PIC18F458]] will use a 10MHz crystal and with the onboard digital phase-locked loop (DPLL) multiply it by 4 to get 40MHz.
+First we talked about tuning the local oscillators: in our case, the PIC18F458 will use a 10MHz crystal and with the onboard digital phase-locked loop (DPLL) multiply it by 4 to get 40MHz.
Although it's better to sync everything together (see below), tuning the PIC's main crystal oscillators could work as well. To do this, we'd need a variable capacitor to tune the crystal circuit to the right frequency. We can get surface mount variable caps, but they're twitchy and who wants something that's mechanical when you've got 15g's on launch. So we discussed tuning the circuit and then replacing the variable cap with a fixed one... but this is difficult since at these low capacitances (10's of pF) it's difficult to measure capacitance and there are all sorts of parasitics that make the variable cap different from a regular cap.
diff --git a/news/2002-04-14.mdwn b/news/2002-04-14.mdwn
index 4aaf180..e53aabe 100644
--- a/news/2002-04-14.mdwn
+++ b/news/2002-04-14.mdwn
@@ -6,7 +6,7 @@ Participants: Jamey, James, Nate, Paul and Andrew
**Overview:**
-We had a grand time today attempting to get the CAN bus up and working... with the key word being "attempt". Our agenda was to get the FC, the MCP2510 devleopment board, and a new (finished last night by modifying an old [[PIC16F877]]+SJA1000 board) [[PIC18F458]] board.
+We had a grand time today attempting to get the CAN bus up and working... with the key word being "attempt". Our agenda was to get the FC, the MCP2510 devleopment board, and a new (finished last night by modifying an old PIC16F877+SJA1000 board) PIC18F458 board.
We had problems right away - we apparently never wrote down how to connect things and what the CAN timing registers should be. So we "rediscovered" and documented them (see [[CanDeviceBusTimings]]) and still couldn't get the CAN bus to work. There were several connection problems at first, but then after those were fixed it seemd like a weird disconnection error... as if the FC's 82527 wasn't responding.
@@ -18,13 +18,13 @@ James and Jamey booted the FC with the CF carrier board mounted on the PC104 sta
**CAN Nodes:**
-Andrew, Paul and Nate got the [[PIC18F458]] board to blink an LED. Oh, the excitement. Actually, frankly, it was exciting, because it was the first attempt to use the ICD2, a [[PIC18F458]] and the latest MPLAB release with the Microchip C-18 compiler... and amazingly, it worked the FIRST time. We were stunned.
+Andrew, Paul and Nate got the PIC18F458 board to blink an LED. Oh, the excitement. Actually, frankly, it was exciting, because it was the first attempt to use the ICD2, a PIC18F458 and the latest MPLAB release with the Microchip C-18 compiler... and amazingly, it worked the FIRST time. We were stunned.
We tried to get the board to send CAN messages, but time was running out by then.
**Task list:**
-- Andrew is going to try and get the [[PIC18F458]] board to spew CAN messages.
+- Andrew is going to try and get the PIC18F458 board to spew CAN messages.
- Nate and Paul should read up on the CAN peripheral in the 18F458 manual.
diff --git a/news/2002-04-28.mdwn b/news/2002-04-28.mdwn
index c99f705..cace1b3 100644
--- a/news/2002-04-28.mdwn
+++ b/news/2002-04-28.mdwn
@@ -6,11 +6,11 @@ Participants: Paul, Larry and Andrew
**Overview:**
-Got the old [[PIC16F877]] + SJA1000 CAN node talking to the MCP2510 development board, hooray. Hopefully the problems we had last week doesn't mean the FC CAN circuitry is toast... my guess is that it was a wiring problem. I added a small connector on the FC for the CAN bus so that it's harder to screw up the wiring now.
+Got the old PIC16F877 + SJA1000 CAN node talking to the MCP2510 development board, hooray. Hopefully the problems we had last week doesn't mean the FC CAN circuitry is toast... my guess is that it was a wiring problem. I added a small connector on the FC for the CAN bus so that it's harder to screw up the wiring now.
Discovered that the MOPS520 has two 120ohm resistors soldered in parallel on the board. Whoops!
-Found out that because the CAN protocol chip is not in the default on state in the [[PIC18F458]], it's possible to complete kill the CAN bus by turning the PORTB pins to grounded outputs. That's bad, we may want to do something in hardware to prevent a locked up node killing the bus. But using watchdog timers may do that for us.
+Found out that because the CAN protocol chip is not in the default on state in the PIC18F458, it's possible to complete kill the CAN bus by turning the PORTB pins to grounded outputs. That's bad, we may want to do something in hardware to prevent a locked up node killing the bus. But using watchdog timers may do that for us.
Larry worked on the Twiki logistics team site. Go Larry go.
diff --git a/news/2002-05-14.mdwn b/news/2002-05-14.mdwn
index 7b1e291..8b296b6 100644
--- a/news/2002-05-14.mdwn
+++ b/news/2002-05-14.mdwn
@@ -9,7 +9,7 @@ Great meeting tonight - thanks to all who came. We started with an introduction
**CAN Node Status:**
- Dennis did a great job of soldering up the IMU CAN board, including the annoyingly small TQFP 18F458. He agreed to do the GPS node board as well, which will enable us to have an IMU and GPS for the June launch.
-- It looks like we'll rely on modifying the [[PIC16F877]] + SJA1000 PCB's that we made in order to use the [[PIC18F458]]. We'll eventually replace them with 18F458 boards, but for now we just don't have time to redo all the boards: so the umbilical, IMU and GPS CAN nodes will all be modified old boards.
+- It looks like we'll rely on modifying the PIC16F877 + SJA1000 PCB's that we made in order to use the PIC18F458. We'll eventually replace them with 18F458 boards, but for now we just don't have time to redo all the boards: so the umbilical, IMU and GPS CAN nodes will all be modified old boards.
- The only new board we still aim on having on the June launch is the 2m uplink system, which Tim and Andrew are currently working on.
**Ground Station Changes:**
diff --git a/news/2002-05-26.mdwn b/news/2002-05-26.mdwn
index 0abf5b9..2f385a2 100644
--- a/news/2002-05-26.mdwn
+++ b/news/2002-05-26.mdwn
@@ -6,7 +6,7 @@ Participants: Andrew, Paul, Nathan
We went over more 18F458 stuff, including:
-- [[PIC18F]] ports.
+- PIC18F ports.
- CAN bus basics.
- Got Nathan's computer up and running with the ICD on the serial bus.
- Decided to kill Paul's computer and convert it to 98SE.
diff --git a/news/2002-06-18.mdwn b/news/2002-06-18.mdwn
index 99ae24c..854c2ae 100644
--- a/news/2002-06-18.mdwn
+++ b/news/2002-06-18.mdwn
@@ -12,7 +12,7 @@ Working backwords, we launch August 3rd. Two weeks before, we freeze code after
We broke the avionics system into three parts:
-**CAN Nodes:** Basically [[PIC18F458]] firmware since the boards are complete - we'll take two weeks to finish up the core drivers, and then we'll spend the next three weeks working on the individual node applications (IMU, GPS, etc).
+**CAN Nodes:** Basically PIC18F458 firmware since the boards are complete - we'll take two weeks to finish up the core drivers, and then we'll spend the next three weeks working on the individual node applications (IMU, GPS, etc).
**FC:** James (with help) will be working on a UDP tool to test the 802.11b... the tool will run on the FC and ground computer and log packet statistics on 802.11b link. There's also the CAN driver and [[CanMuxer]] code, of course.
diff --git a/news/2002-06-25.mdwn b/news/2002-06-25.mdwn
index 1c99370..aedac62 100644
--- a/news/2002-06-25.mdwn
+++ b/news/2002-06-25.mdwn
@@ -8,11 +8,11 @@
**CAN Nodes:** Paul and Nate's CAN node development systems are FINALLY up and running and three weeks of tool and Windows hell... their job is to blink their blinky lights in the mainline and in the ISR by Sunday so we can get to work on applications. The final setup:
-- "MISC" CAN node with a [[PIC18F458]] running at 20MHz and a few LEDs
+- "MISC" CAN node with a PIC18F458 running at 20MHz and a few LEDs
- MPLAB ICD2 w/ a custom cable to the CAN node
- MPLAB 5.62
- MCC18 (PIC C compiler) version 2.00
-- [[LV2CORE]] firmware framework (see [[CanNodeFirmware]])
+- LV2CORE firmware framework (see [[CanNodeFirmware]])
- MCP2510 development board w/ Kvaser's CAN King software v4.0.1
[[tag avionics software]]
diff --git a/news/2002-07-07.mdwn b/news/2002-07-07.mdwn
index 2211193..d7d12b5 100644
--- a/news/2002-07-07.mdwn
+++ b/news/2002-07-07.mdwn
@@ -4,7 +4,7 @@
**Participants:** Andrew, Paul, Nate, Jamey and James.
-The CAN drivers for the [[PIC18F458]] are now half done - the transmit side now works. It turns out that the last week of frustration was due to two wires being reversed. Ack. After that was fixed, it worked great.
+The CAN drivers for the PIC18F458 are now half done - the transmit side now works. It turns out that the last week of frustration was due to two wires being reversed. Ack. After that was fixed, it worked great.
Paul, Nate and Andrew (and Jamey too) went over the CAN node firmware framework and improved it on the fly - new code was posted. We talke a bit about the GPS and the overlay board applications as well.
diff --git a/news/2002-09-22/logistics/people.mdwn b/news/2002-09-22/logistics/people.mdwn
index 80453a1..483b0ae 100644
--- a/news/2002-09-22/logistics/people.mdwn
+++ b/news/2002-09-22/logistics/people.mdwn
@@ -341,35 +341,35 @@ For a schedule and a what to bring list, see: [[news/2002-09-22/logistics]]
<table border=1 cellpadding=0 cellspacing=0>
<tr>
<td> Andrew Greenberg </td>
- <td>[[KD7CJT]]</td>
+ <td>KD7CJT</td>
</tr>
<tr>
<td> Glenn LeBrasseur </td>
- <td>[[KJ7SU]]</td>
+ <td>KJ7SU</td>
</tr>
<tr>
<td> Jimmy Ward </td>
- <td>[[KC7KTN]]</td>
+ <td>KC7KTN</td>
</tr>
<tr>
<td> Larry Leach </td>
- <td>[[KA7KLE]]</td>
+ <td>KA7KLE</td>
</tr>
<tr>
<td> Dave Turner </td>
- <td>[[KC7ZVL]]</td>
+ <td>KC7ZVL</td>
</tr>
<tr>
<td> Dennis Young </td>
- <td>[[KC7FTZ]]</td>
+ <td>KC7FTZ</td>
</tr>
<tr>
<td> Bart Massey </td>
- <td>[[KD7SQH]]</td>
+ <td>KD7SQH</td>
</tr>
<tr>
<td> Keith Packard </td>
- <td>[[KD7SQG]]</td>
+ <td>KD7SQG</td>
</tr>
</table>
diff --git a/news/2003-10-06.mdwn b/news/2003-10-06.mdwn
index 1939dc6..ad07de6 100644
--- a/news/2003-10-06.mdwn
+++ b/news/2003-10-06.mdwn
@@ -8,6 +8,6 @@ Glenn did the first round of testing the CPAs which were fabbed in the desert of
The three CPA antennas were tested in the PSU microwave lab using an HP 8753E Vector Network Analyzer. The test measured the S11 parameter.
-Attached below are the screen dump images made by the [[HP8753E]] VNA on 7-Oct-2003. The 1.2 GHz test actually shows resonance. Included also is the 1.2 GHz SWR graph with the marker positioned at resonance to show the minimum SWR and resonant frequency. This will allow us to reverse-design to find an actual real world Er, and then compensate the design. The tests at 2.4 GHz and 1.5 GHz need to be performed again to find resonance to check this reverse-design procedure.
+Attached below are the screen dump images made by the HP8753E VNA on 7-Oct-2003. The 1.2 GHz test actually shows resonance. Included also is the 1.2 GHz SWR graph with the marker positioned at resonance to show the minimum SWR and resonant frequency. This will allow us to reverse-design to find an actual real world Er, and then compensate the design. The tests at 2.4 GHz and 1.5 GHz need to be performed again to find resonance to check this reverse-design procedure.
[[tag comm]]
diff --git a/news/2003-10-13.mdwn b/news/2003-10-13.mdwn
index 020b5aa..aa41603 100644
--- a/news/2003-10-13.mdwn
+++ b/news/2003-10-13.mdwn
@@ -44,7 +44,7 @@ FC: 415mA<br /> FC and Wifi w/PA: 1.05A<br />
2. Total maximum power draw: 2.85A @ 13.5V = 38.5W
3. We hypothesized that a good launch would need only about 20 minutes of full power time: 2 minutes on the pad, 2 minutes to apogee, 15 minutes to the ground. But if something went wrong on the pad, or the main parachute was deployed at apogee, then this time could be extended to as long as an hour or more. We decided one hour to 50% depth of discharge was reasonable for a battery pack to handle: that's about 6 AHr.
4. Our current batteries are not capable of handling 2.8A. Since they're 1.5AHr (rated at 2.5mA, whoops), we can't count on them being anything close to that 1.5A at 2.8/2 = 1.4A (for each set of two packs in parallel). So we decided that if we fly it with the Li primary batteries, we'll extend the pack out by another layer of batteries to fly 8 Li batteries together (700mA/battery pack, which is more reasonable for the Li to handle). Tim R. is going to test one of the Li batteries on an active load he's building so we can find out exactly how much we can expect from these batteries.
-5. After we revamp the power/battery document, we're going to choose a smart battery (think laptop battery) which we can use off the shelf with our own charger. This way we get the smarts of the smart battery - precision charge counter and SMBus ([[I2C]]) interface - and only have to build a charger to charge it. In fact, if we find a smart battery with Li Ion cells we know about, like the Panasonic 18650's, then we can always keep the smart battery controller and swap the cells if they die off. Tim R. is taking on the research and development on this "next gen" power system. Go Tim go!
+5. After we revamp the power/battery document, we're going to choose a smart battery (think laptop battery) which we can use off the shelf with our own charger. This way we get the smarts of the smart battery - precision charge counter and SMBus (I2C) interface - and only have to build a charger to charge it. In fact, if we find a smart battery with Li Ion cells we know about, like the Panasonic 18650's, then we can always keep the smart battery controller and swap the cells if they die off. Tim R. is taking on the research and development on this "next gen" power system. Go Tim go!
### <a name="Links"></a> Links
diff --git a/news/2004-02-12.mdwn b/news/2004-02-12.mdwn
index 2a5c20d..af222a5 100644
--- a/news/2004-02-12.mdwn
+++ b/news/2004-02-12.mdwn
@@ -39,7 +39,7 @@ Marilyn said the finest resolution of volume measurement they had was +/- 1 mL w
</tr>
<tr>
<td> Scale information </td>
- <td> Sartorius model [[A200S]]; s/n 38110191; Room 142 </td>
+ <td> Sartorius model A200S; s/n 38110191; Room 142 </td>
</tr>
<tr>
<td> Weight of typical weight boat </td>
diff --git a/news/2004-05-02.mdwn b/news/2004-05-02.mdwn
index f46666f..bda62b8 100644
--- a/news/2004-05-02.mdwn
+++ b/news/2004-05-02.mdwn
@@ -26,7 +26,7 @@ Start with a v3 Misc. CAN node:
- New, more reasonable size (same as recovery node?)
- linear 5V micropower power supply... LOW NOISE! Ferrites, filter caps, etc.
-- [[PIC18F458]] 1/10MHz crystal (PLL'd to 40MHz = 10MIPS) running [[PicCore]]
+- PIC18F458 1/10MHz crystal (PLL'd to 40MHz = 10MIPS) running [[PicCore]]
- JED connectors for CAN and ICD2
- Don't forget taps for the CAN and UART.
diff --git a/news/2004-06-27.mdwn b/news/2004-06-27.mdwn
index 0b44a80..4c3733a 100644
--- a/news/2004-06-27.mdwn
+++ b/news/2004-06-27.mdwn
@@ -70,7 +70,7 @@ Here's some notes from the conversation with Glenn:
- Last minute reconfigurations on the rail - "rocket tape" (green ducttape)
- Use MDM connectors - a small D sub (via Newark or Glenair) with wires pre-installed.
- Latch ups in microcontroller - requires _external_ _\_power cycling_ watchdogs to unlatch it (within milliseconds)
-- Did a 700km flight with a [[PIC16F84]] and no watchdog.
+- Did a 700km flight with a PIC16F84 and no watchdog.
- Always use connectors going into a box
- Uses Bardington magnetometers for nav
- Uses brass, Ti, nonmagnetic stainless, teflon coax can have a steel center conductor - non-magnetic stainless from McMaster Carr
diff --git a/news/2004-10-27.mdwn b/news/2004-10-27.mdwn
index 27984e2..6cfd84d 100644
--- a/news/2004-10-27.mdwn
+++ b/news/2004-10-27.mdwn
@@ -19,7 +19,7 @@ Bart, Keithp, Jamey, Ian, Peter, Josh, Boyd
- the IMU reader thread processes IMU messages (as in filters) and posts them (filtered) to the blackboard.
- Logger
- All writes to the logger go through a giant ring buffer which is write locked (using allocate, write and read pointers).
- - Logger now writes to [[FC2NET]] when an object in the giant ring buffer has a flag saying it's outbound to the net.
+ - Logger now writes to FC2NET when an object in the giant ring buffer has a flag saying it's outbound to the net.
- Sequencer
- Now runs at a constant rate and reads/writes to the blackboard.
diff --git a/news/2004-12-07.mdwn b/news/2004-12-07.mdwn
index 7c5cbc7..783e870 100644
--- a/news/2004-12-07.mdwn
+++ b/news/2004-12-07.mdwn
@@ -194,7 +194,7 @@ At this point Keith left, taking our notes with him. But we got them back.
# <a name="pressure.c"></a> pressure.c
-- Tim will double check pressure.c algorithms (set\_pressure\_base and process\_pressure) by comparing [[LV1B]] GPS data to [[LV1B]] pressure data.
+- Tim will double check pressure.c algorithms (set\_pressure\_base and process\_pressure) by comparing LV1B GPS data to LV1B pressure data.
# <a name="report_state.c"></a> report\_state.c
diff --git a/news/2004-12-22.mdwn b/news/2004-12-22.mdwn
index 41124a5..76d04d9 100644
--- a/news/2004-12-22.mdwn
+++ b/news/2004-12-22.mdwn
@@ -2,7 +2,7 @@
Josh, Tim, Andrew locally and Jamey remotely via IRC and speakerphone
-- Verified that the pressure sensor works and that Andrew is an idiot: the slight gain from the 6.025V [[MPX5100A]] supply makes pressure near sea level saturate the sensor. So we won't be able to launch from near sea level. Whoops.
+- Verified that the pressure sensor works and that Andrew is an idiot: the slight gain from the 6.025V MPX5100A supply makes pressure near sea level saturate the sensor. So we won't be able to launch from near sea level. Whoops.
- Used Mathematica to revamp the pressure.c calculations by comparing the LV1b IMU pressure data to the LV1b GPS data. Neat!
diff --git a/news/2005-03-22.mdwn b/news/2005-03-22.mdwn
index d9632dd..e2e6ff7 100644
--- a/news/2005-03-22.mdwn
+++ b/news/2005-03-22.mdwn
@@ -71,7 +71,7 @@ He suggested we contact <http://www.rsmicro.com/> since their LCS series looked
- <http://www.klmicrowave.com/ecommerce/listproducts.asp?categoryid=63>
- <http://www.digikey.com/> has:
- - Panasonic SAW filter [[EFCH1575TCB1]]
+ - Panasonic SAW filter EFCH1575TCB1
- <http://www.abracon.com/SAW%20Filter/AFS1575.42.pdf><br />(-40dB stop band, 1.5dB insertion loss, 4$ from DigiKey in singles)
Long shots:
diff --git a/news/2005-07-03.mdwn b/news/2005-07-03.mdwn
index 928101e..4d12d32 100644
--- a/news/2005-07-03.mdwn
+++ b/news/2005-07-03.mdwn
@@ -8,7 +8,7 @@ Who: Andrew, Jamey, Tim, Bart, Jay, Keith, Ryanb, Frank, Dave, Holly, Richard, E
Previous evening prep:
-- Fix [[TM2K]] feeds
+- Fix TM2K feeds
- Prep the "ground table" (ground station and near the LT) to slide into the back of a van/truck
- LTC rewire to bypass solar charger load
- Check systems
diff --git a/news/2005-10-06.mdwn b/news/2005-10-06.mdwn
index eea40af..0fe4241 100644
--- a/news/2005-10-06.mdwn
+++ b/news/2005-10-06.mdwn
@@ -42,7 +42,7 @@ January Goals:
1. Help the software team get the new PPC FC up and running - get a PCI-104 to PCMCIA/PC Card adapter, flash memory, etc.
2. Get GPL-GPS up and running with the new FC (probably just over the UART, no need for CAN).
-3. Determine if Glenn and Sarah can do their senior capstone project on the design of new [[ARM7TDMI]]-based CAN nodes.
+3. Determine if Glenn and Sarah can do their senior capstone project on the design of new ARM7TDMI-based CAN nodes.
4. Have a true design and schedule document for the new avionics system
## <a name="Software Team"></a> Software Team